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are  a  prominent  part  of  expert  problem  solving  in  many  other  engineering  disciplines,  such  as  electrical 
and  mechanical  engineering.  The  notion  of  inspection  methods  in  programming  developed  in  this  work 
is  motivated  by  similar  notions  in  other  areas  of  engineering,  j 

This  work  is  also  motivated  by  current  practical  concerns  in  the  area  of  software  engineering.  The 
inadequacy  of  current  programming  technology  is  universally  recognized.  Part  of  the  solution  to  this 
problem  will  be  to  increase  the  level  of  automation  in  programming.  1  believe  that  the  next  major  step  in 
the  evolution  of  more  automated  programming  will  be  interactive  systems  which  provide  a  mixture  of 
partially  automated  program  analysis,  synthesis  and  verification.  One  such  system  being  developed  at 
MIT,  called  the  programmer’s  apprentice .  is  the  immediate  intended  application  of  this  work. 

^"his  report  concentrates  on  the  knowledge  base  of  the  programmer’s  apprentice,  which  is  in  the 
form  of  a  taxonomy  of  commonly  used  algorithms  and  data  structures.  To  the  extent  that  a  programmer 
is  able  to  construct  and  manipulate  programs  in  terms  of  the  forms  in  such  a  taxonomy,  he  may  relieve 
himself  of  many  details  and  generally  raise  the  conceptual  level  of  his  interaction  with  the  system,  as 
compared  with  present  day  programming  environments.  Also,  since  it  is  practical  to  expend  a  great  deal 
of  effort  pre-analyzing  the  entries  in  a  library,  the  difficulty  of  verifying  the  correctness  of  programs 
constructed  this  way  is  correspondingly  reduced.  The  feasibility  of  this  approach  is  demonstrated  by  the 
design  of  an  initial  library  of  common  techniques  for  manipulating  symbolic  data. 

This  document  also  reports  on  the  further  development  of  a  formalism  called  the  plan  calculus  for 
specifying  computations  in  a  programming  language  independent  manner.  ITiis  formalism  combines 
both  data  and  control  abstraction  in  a  uniform  framework  and  has  facilities  for  representing  multiple 
points  of  view  and  side  effects. 
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Abstract 


The  work  reported  here  lies  in  the  area  of  overlap  between  artificial  intelligence  and  software 
engineering.  As  research  in  artificial  intelligence,  it  is  a  step  towards  a  model  of  problem  solving  in  the 
domain  of  programming.  In  particular,  this  work  focuses  on  the  routine  aspects  of  programming  which 
involve  the  application  of  previous  experience  with  similar  programs.  I  call  this  programming  by 
inspection. 

Programming  is  viewed  here  as  a  kind  of  engineering  activity.  Analysis  and  synthesis  by  inspection 
are  a  prominent  part  of  expert  problem  solving  in  many  other  engineering  disciplines,  such  as  electrical 
and  mechanical  engineering.  The  notion  of  inspection  methods  in  programming  developed  in  this  work 
is  motivated  by  similar  notions  in  other  areas  of  engineering. 

This  work  is  also  motivated  by  current  practical  concerns  in  the  area  of  software  engineering.  The 
inadequacy  of  current  programming  technology  is  universally  recognized.  Part  of  the  solution  to  this 
problem  will  be  to  increase  the  level  of  automation  in  programming.  I  believe  that  the  next  major  step  in 
the  evolution  of  more  automated  programming  will  be  interactive  systems  which  provide  a  mixture  of 
partially  automated  program  analysis,  synthesis  and  verification.  One  such  system  being  developed  at 
MIT,  called  the  programmer’s  apprentice,  is  the  immediate  intended  application  of  this  work. 

This  report  concentrates  on  the  knowledge  base  of  the  programmer’s  apprentice,  which  is  in  the 
form  of  a  taxonomy  of  commonly  used  algorithms  and  data  structures.  To  the  extent  that  a  programmer 
is  able  to  construct  and  manipulate  programs  in  terms  of  the  forms  in  such  a  taxonomy,  he  may  relieve 
himself  of  many  details  and  generally  raise  the  conceptual  level  of  his  interaction  with  the  system,  as 
compared  with  present  day  programming  environments.  Also,  since  it  is  practical  to  expend  a  great  deal 
of  effort  pre-analyzing  the  entries  in  a  library,  the  difficulty  of  verifying  the  correctness  of  programs 
constructed  this  way  is  correspondingly  reduced.  The  feasibility  of  this  approach  is  demonstrated  by  the 
design  of  an  initial  library  of  common  techniques  for  manipulating  symbolic  data. 

This  document  also  reports  on  the  further  development  of  a  formalism  called  the  plan  calculus  for 
specifying  computations  in  a  programming  language  independent  manner.  This  formalism  combines 
both  data  and  control  abstraction  in  a  uniform  framework  and  has  facilities  for  representing  multiple 
points  of  view  and  side  effects. 
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INI  INDUCTION  1 


CHAPTER  ONE 
INTRODUCTION 


1.1  Inspection  Methods 

Inspection  methods  are  a  distillation  of  the  collective  experience  of  solving  many  problems  in  a 
particular  domain.  The  essence  of  this  experience  is  a  taxonomy  of  common  problem  forms.  The  first 
step  of  any  inspection  method  is  to  recognize  a  familiar  form  embedded  in  a  given  problem.  Associated 
with  each  such  problem  form  is  either  an  explicit  solution  or,  more  generally,  the  form  of  the  answer.  In 
sufficiently  complex  situations,  debugging  is  also  an  unavoidable  part  of  the  use  of  inspection  methods. 
The  role  of  debugging  in  problem  solving  has  been  investigated  by  Sussman  [68,67];  it  is  not  part  of  the 
focus  of  this  work. 

For  example,  analysis  of  the  termination  conditions  of  a  program  is  often  done  by  inspection.  If 
you  recognize  a  loop  that  counts  up  by  one  from  an  initial  number  up  to  a  fixed  greater  number,  then  you 
know  from  experience  that  it  always  terminates.  Similarly,  experienced  programmers  know  a  repertoire 
of  standard  operations  on  sets  and  their  implementations  for  variety  of  set  representations.  In  synthesis 
by  inspection,  once  a  programmer  recognizes  that  a  problem  calls  for  one  of  these  operations,  he  can 
implement  it  immediately.  Program  verification  can  also  often  done  by  inspection.  Most  of  the  difficult 
deductive  steps  (typically  the  inductive  arguments)  can  be  embedded  in  pre-proven  lemmas  which  are 
associated  with  the  standard  forms.  All  that  remains  is  to  combine  these  lemmas  appropriately  in  the 
proof  of  the  particular  program. 

An  Engineering  Vocabulary 

Another  significant  characteristic  of  the  use  of  inspection  methods  in  engineering  is  that  the 
common  forms  acquire  names  which  become  part  of  the  standard  working  vocabulary  of  experts  in  the 
field.  These  names  for  intermediate  level  constructs  supplement  the  primitive  vocabulary  of  the  domain. 
For  example,  the  primitive  vocabulary  of  currents,  voltages  and  resistances  is  formally  adequate  for 
specifying  a  wide  range  of  electrical  functions.  Experienced  electrical  engineers,  however,  use  a  much 
richer  vocabulary  including  such  concepts  as  scries  and  parallel  configuration,  voltage  divider,  cascode 
connection,  and  so  on.  Similarly,  an  experienced  programmer  knows  much  more  titan  the  the  primitive 
programming  language  constructs,  such  as  tests,  iterations,  arrays,  assignments,  and  so  on.  An 
experienced  programmer  is  also  familiar  with  many  other  more  abstract  concepts  such  as  lists,  hash  tables, 
search  loops,  and  splicing. 

A  shared  intermediate  level  vocabulary  is  very  important  for  communication  between  experts.  In 
many  fields  this  vocabulary  has  been  codified  and  is  taught  as  part  of  the  standard  education  of  novices. 
This  implies  that  facility  with  the  appropriate  intermediate  vocabulary  is  an  essential  component  of  an 
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intelligent  interactive  system  which  is  going  to  help  experts  in  some  field.  Chapter  Two  illustrates  this 
point  for  the  programmer’s  apprentice  system  in  particular. 

Uniform  General  Methods 

Many  areas  of  engineering  (and  related  fields  such  as  applied  mathematics)  have  over  a  period  of 
time  developed  powerful  general  methods  which  solve  a  wide  range  of  problems  of  a  given  kind.  For 
example,  general  circuit  analysis  techniques  involving  node  and  cut  sets  and  the  inversion  of  matrices 
have  been  known  for  a  long  time.  Recently,  a  very  powerful  general  method  for  symbolic  integration  has 
been  discovered  by  Risch.  Why  then  do  inspection  methods  continue  to  be  of  interest? 

General  methods  gain  their  power  by  operating  in  a  uniform  way  at  the  most  primitive  level  of 
vocabulary  of  the  domain.  This  causes  two  serious  problems:  the  methods  are  inefficient  and  the  results 
are  difficult  for  users  to  interpret.  For  example,  the  Risch  algorithm  is  usually  used  only  as  a  last  resort, 
even  by  automated  systems  like  Macsyma  [421,  because  inspecting  an  integral  for  one  of  the  many  well- 
known  forms  is  comparatively  inexpensive,  and  if  one  is  recognized,  the  answer  can  be  computed  much 
more  quickly  than  by  the  algorithm.  Similarly,  general  circuit  analysis  techniques  involving  node  and  cut 
sets  and  the  inversion  of  matrices  are  seldom  employed  by  expert  circuit  designers  because  the'  are  so 
laborious  in  comparison  to  decomposing  a  circuit  into  familiar  patterns  with  known  behavior  forms. 
Furthermore  the  decomposition  into  standard  forms  usually  coincides  with  the  modules  of  the  design 
being  explored. 

Because  of  these  difficulties,  experts  tend  to  employ  uniform  general  methods  only  as  a  last  resort. 
Whenever  possible  they  try  to  work  with  familiar  special  cases  which  can  be  solved  by  inspection.  In  fact, 
this  behavior  is  usually  taken  as  one  of  the  distinguishing  characteristics  of  being  an  expert. 

General  methods  have  recently  been  developed  in  the  area  of  programming  also.  For  example,  a 
general  method  for  program  verification  due  originally  to  Floyd  [26]  and  Hoare  [35]  decomposes  the 
problem  into  two  steps.  The  first  step  is  the  generation  of  verification  conditions,  in  which  specifications 
of  the  desired  behavior  of  the  program  arc  combined  with  the  axioms  for  each  language  primitive  in  the 
program,  yielding  a  single  formula  to  be  proved  valid.  This  formula  is  then  passed  to  a  general  purpose 
theorem  proven  Unfortunately,  if  the  program  is  incorrect,  which  is  the  most  common  case,  the  manner 
in  which  the  proof  of  the  verification  conditions  fails  provides  little  guidance  to  the  user  about  how  to 
correct  the  original  program.  Verification  by  inspection,  while  it  is  not  as  powerful,  docs  not  suffer  from 
this  problem  of  incomprehensibility.  Errors  are  detected  by  inspection  either  by  recognizing  a  known 
pattern  whose  pre-proven  properties  contradict  the  desired  specifications,  or  by  recognizing  a  suspiciously 
close  match  to  a  known  pattern.  In  either  case,  the  nature  of  the  discrepancy  can  be  communicated  to  the 
user  in  terms  of  familiar  engineering  vocabulary. 

The  analysis  of  programs  with  side  effects  is  another  area  in  which  general  methods  have  failed  to 
supplant  inspection.  Some  work  has  been  done  on  representing  and  reasoning  about  side  effects  in 
programs  (64),  but  the  general  methods  developed  thus  far  are  clumsy  and  computationally  expensive. 
Furthermore,  there  is  reason  to  believe  that  there  arc  fundamental  limitations  to  the  effectiveness  of 
general  methods  in  this  area.  Programs  with  an  unconstrained  use  of  side  effects  (such  as  rplaca  and 
rplacd  in  I.isp)  arc  extremely  difficult  to  understand  even  for  the  most  expert  human  programmers.  This 
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has  led  some  to  advocate  the  extreme  position  of  banning  side  effects  entirely  in  new  languages  and 
systems.  However,  there  are  also  good  arguments  that  side  effects  are  crucial  for  the  modularity  and 
efficiency  of  certain  programs  [66].  The  resolution  of  this  apparent  conflict  lies  in  the  observation  that 
side  effects  arc  typically  used  only  in  very  stylized  forms,  such  as  to  splice  nodes  in  and  out  of  a  linked  list, 
to  update  a  global  data  base,  and  so  on.  By  constructing  a  library  of  these  standard  plans  and  their 
properties,  analysis  of  side  effects  by  inspection  can  suffice  for  most  practical  purposes. 

Education 

The  importance  of  inspection  methods  in  engineering  problem  solving  is  also  reflected  in 
educational  practices.  The  introductory  parts  of  most  engineering  curricula  first  acquaint  students  with 
the  standard  forms  of  the  discipline.  Only  much  later,  after  the  students’  intuitions  arc  developed,  arc  the 
uniform  general  methods  taught.  For  example,  electrical  engineering  students  are  first  taught  how  to 
predict  the  behavior  of  certain  standard  circuits  (e.g.  oscillators),  and  how  to  implement  certain  common 
signal  processing  functions  (e.g.  filters),  before  they  are  taught  general  tools  for  analyzing  and 
synthesizing  circuits.  In  programming  also,  we  begin  with  the  craft  lore  of  standard  algorithms  and  data 
structures  before  introducing  any  general  program  analysis,  synthesis  or  verification  methods. 

L.2  Multiple  Points  of  View 

Ihe  range  of  applicability  of  inspection  methods  rests  crucially  on  the  ability  to  recognize  familiar 
forms  in  various  contexts.  There  are  many  different  ways  in  which  the  recognition  of  familiar  forms  can 
be  obscured.  For  example,  in  electrical  engineering  a  standard  circuit  may  not  appear  to  be  familiar 
because  some  components  are  in  parallel  rather  than  in  scries,  or  vice  versa.  Similar  difficulties  also  arise 
in  programs.  For  example,  the  placement  of  exit  tests  other  than  at  the  top  or  bottom  of  a  loop  can 
obscure  the  recognition  of  standard  loop  forms. 

Various  techniques  have  been  developed  in  different  fields  to  overcome  such  complications.  These 
techniques  are  variously  called  equivalences,  transformations,  or  models.  All  of  these  can  be  be  thought 
of  as  ways  of  providing  the  user  with  different  points  of  view  on  a  problem.  Sometimes  a  different  point 
of  view  is  necessary  in  order  to  use  inspection  methods  at  all.  Sometimes  several  different  points  of  view 
each  contribute  some  part  of  the  solution.  For  example,  in  the  analysis  and  synthesis  of  electrical  circuits, 
equivalence  theorems  (such  as  Thevcnin-Norton)  arc  a  basic  tool  for  rearranging  the  topology  of  circuits 
to  match  standard  forms.  Electrical  engineers  also  use  views  in  which  certain  features  of  the  problem  are 
ignored  —  the  so-called  AC  (sinusoidal  steady  state)  and  DC  (direct  current)  models  arc  examples.  In 
one  model  certain  components  become  open  circuits,  while  in  the  other  they  become  shorts.  Since  the 
circuit  in  each  model  is  simpler  than  in  the  full  circuit  view',  the  user  is  more  likely  to  be  able  to  use 
inspection.  (It  is  also  an  important  feature  of  these  particular  two  views  that  results  derived  in  them  can 
be  simply  combined  to  give  a  complete  analysis  of  the  circuit.) 

Multiple  points  of  view  are  also  important  in  understanding  programs.  Program  transformations 
can  be  used  to  move  the  position  of  exit  tests  in  loops,  and  thereby  increase  the  power  of  inspection 
methods  which  recognize  loop  forms.  In  the  area  of  data  structures,  it  is  often  necessary  to  view  a  single 
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structure  from  two  different  points  of  view,  each  of  which  captures  a  different  generalization.  For 
example,  a  Lisp  list  can  be  viewed  both  as  a  recursive  structure  (the  tail  of  a  list  is  a  list)  and  as  a  labelled 
directed  graph  (where  the  nodes  are  Lisp  cells  connected  by  the  cor  relation  and  labelled  by  the  car 
relation).  The  first  view  is  appropriate  for  understanding  cons  and  cdr  as  push  and  pop  operations.  The 
second  view  brings  to  bear  a  programmer's  experience  with  standard  graph  manipulations  in  order  to 
understand  rplacd  as  the  operation  of  splicing  out  a  node.  A  single  Lisp  list  may  be  used  in  both  these 
ways  in  a  single  program. 

Another  example  of  point  of  view  in  programming  is  what  1  call  the  "steady  state”  model  of  loops 
(and  in  general,  recursions).  In  this  view,  exit  tests  are  ignored  in  order  to  recognize  the  basic  iteration 
and  recursion  forms,  such  as  counting,  summing,  car-cdr  recursion,  etc.  This  view  is  similar  to  the  AC 
model  in  electronic  circuits,  in  that  it  can  be  simply  combined  with  other  views  to  construct  a  complete 
description.  For  example,  the  counting  part  of  a  loop  can  be  abstracted  as  generating  an  infinite  sequence 
of  numbers,  which  is  truncated  by  the  exit  test. 

As  we  will  see  later  in  this  chapter,  a  mechanism  for  representing  multiple  points  of  view  is  an 
important  part  of  the  formalization  of  inspection  methods  in  programming. 

Overlapping  Implementations 

A  kind  of  recognition  difficulty  which  arises  often  in  engineering  domains  is  when  the 
implementations  of  two  distinct  abstract  functions  overlap.  This  means  that  a  single  component  at  the 
implementation  level  plays  a  role  in  two  distinct  forms.  For  example,  a  screw  in  a  mechanical  device  may 
fasten  two  plates  together  and  also  provide  a  fulcrum  about  which  to  pivot  a  lever.  In  a  radio-frequency 
amplifier,  an  inductor  may  be  both  part  of  a  resonant  circuit  in  the  AC  model  and  also  part  of  the  bias 
network  of  a  transistor  in  the  DC  model.  This  kind  of  "bumming”  is  not  just  a  feature  of  arcane 
programming  —  it  is  an  essential  part  of  good  engineering. 

For  example,  consider  the  following  program  which  computes  both  the  maximum  and  the 
minimum  of  a  non-empty  list  of  numbers. 

(OEFUN  MAX-MIN  (L) 

(LET  ((MAX  (CAR  L) ) 

(HIM  (CAR  L))) 

(MAPC  ’(LAMBDA  (N)  (CONO  ((>  N  MAX)  (SETQ  MAX  «))) 

(COND  ((<  N  MIN)  (SETQ  MIN  N)))) 

(COR  L)) 

(CONS  MAX  MIN))) 

The  standard  loop  plan  for  finding  the  maximum  (or  minimum)  element  of  a  list  has  three  principal 
parts:  an  initialization  (here  (car  l>),  an  enumeration  of  the  elements  of  the  list  (here  mapc).  and  an 
accumulation  which  tests  each  element  to  see  if  it  is  the  largest  (or  smallest)  found  so  far.  The  diagram 
below  indicates  how  max-min  can  be  analyzed  in  terms  of  this  plan. 
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The  top  node  in  this  diagram  represents  the  entire  program.  At  the  next  level,  the  program  is 
viewed  as  the  combination  of  two  plans,  one  which  finds  the  maximum  and  one  which  finds  the 
minimum.  The  third  level  shows  how  the  more  primitive  components  of  the  program  are  grouped  and 
viewed  as  the  implementation  of  these  two  plans.  There  are  only  five  nodes  at  this  level  rather  than  six 
because  the  list  enumeration  is  shared  between  the  implementation  of  maximum  and  of  minimum.  It 
must  be  simultaneously  viewed  as  filling  a  role  in  both  plans. 

This  type  of  analysis  is  a  violation  of  strictly  hierarchical  decomposition,  which  is  currently  the 
dominant  technique  in  program  design.  We  have  found,  however,  that  it  is  not  always  possible  to 
maintain  a  strictly  hierarchical  analysis  and  at  the  same  time  capture  the  appropriate  generalizations. 

Implementation  relationships  are  treated  here  as  points  of  view  which  may  overlap.  This  approach 
has  the  advantage  of  allowing  the  efficiency  of  implementation  exemplified  by  the  max-min  program 
above  (as  compared  to  a  strictly  hierarchical  implementation  with  two  separate  loops),  while  still 
capturing  the  similarities  between  this  program  and  programs  which  calculate  only  the  maximum  or  only 
the  minimum. 

1.3  The  Plan  Calculus 

A  key  issue  in  formalizing  the  use  of  inspection  methods  in  a  particular  domain  is  the 
representation  of  standard  forms.  Part  of  the  work  reported  here  has  been  to  further  develop  a 
programming  language  independent  formalism,  called  the  plan  calculus,  for  representing  standard  data 
and  control  structure  forms  (called  plans)  in  programming. 

This  section  introduces  the  plan  calculus  and  points  out  some  of  its  important  features.  A  more 
detailed  definition  of  plans  is  the  topic  of  Chapter  Four.  The  plan  calculus  is  an  outgrowth  of  earlier 
work  by  the  author  in  collaboration  with  Shrobe  [55]  and  Waters  [56].  The  important  features  of  the  plan 
calculus  discussed  in  this  section  are  as  follows. 

•  Wide  Spectrum  Specification 

•  Control  and  Data  Abstraction 

•  Mutable  Objects 

•  Programming  Language  Independence 
.  •  Multiple  Points  of  View 

•  Additivity 

•  Verifiability 

•  Dependencies 


! 
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The  plan  calculus  is  made  up  of  two  major  components:  plans  and  overlays.  Basically,  a  plan  is  the 
specification  of  a  computation.  Overlays  represent  the  relationship  between  two  different  points  of  view 
on  a  computation,  each  of  which  is  specified  by  a  plan. 

Programming  is  viewed  here  as  a  process  involving  the  construction  and  manipulation  of 
specifications  at  various  levels  of  abstraction.  In  this  view,  there  is  no  fundamental  distinction  between 
specifications  and  programs.  A  program  (e.g.  in  Lisp)  is  merely  a  specification  which  is  detailed  enough 
to  be  carried  out  by  some  particular  interpreter.  This  view  is  consistent  with  the  current  trend  in 
computer  science  towards  wide  spectrum  languages.  The  advantage  of  this  approach  is  that  various  parts 
of  a  program  design  can  be  refined  to  different  degrees  without  intervening  shifts  of  formalism. 

Plan 


Computations  are  viewed  here  as  composed  of  three  types  of  primitives:  operations,  tests,  and  data 
objects.  There  are  three  corresponding  types  of  primitive  specifications  in  the  plan  calculus:  input-output 
specifications,  test  specifications  and  object  type  specifications.  Operations  are  specified  by  input-output 
specifications  (preconditions  and  postconditions).  Tests  are  specified  by  whether  they  succeed  or  fail 
when  a  given  relation  holds  between  the  inputs.  The  primitive  object  types  used  in  this  work  are 
numbers,  sets  and  functions. 

Hierarchy  is  represented  by  composite  plans.  Each  composite  plan  specifics  a  set  of  local  names  for 
its  parts  (called  role  names)  and  a  set  of  constraints  which  must  hold  between  them.  There  are  two  kinds 
of  composite  plans,  according  to  the  types  of  the  parts. 

Data  plans  specify  data  structures  whose  parts  are  primitive  data  objects  or  other  data  structures. 
Data  plans  thus  embody  a  kind  of  data  abstraction.  For  example.  List  is  a  data  plan  with  two  roles  named 
Head  and  Tail.  The  Head  of  a  list  may  be  an  object  of  any  type,  but  the  Tail  is  constrained  to  be  cither  an 
instance  of  List  or  the  distinguished  object,  Nil  ("the  empty  list").  Data  plans  are  also  used  to  represent 
common  implementation  forms.  For  example,  a  data  plan  called  Segment  is  shown  in  Fig.  1-1.  Data 
objects  are  indicated  in  plan  diagrams  by  ovals.  This  plan  has  three  roles  named 

Base  (a  sequence). 

Upper  (a  natural  number),  and 
Ixiwcr  (a  natural  number), 

and  the  following  constraints: 

(i)  The  Upper  number  is  less  than  or  equal  to  the  length  of  the  Base  sequence. 

(ii)  The  Lower  number  is  less  than  or  equal  to  the  length  of  the  Base  sequence. 

(iii)  The  Lower  number  is  less  than  or  equal  to  the  Upper  number. 

This  data  plan  (and  special  cases  of  it)  is  commonly  used  to  implement  other  data  abstractions,  such  as 
lists  and  queues. 

Primitive  data  objects  and  data  structures  arc  mutable.  For  primitive  data  objects,  this  means  that 
the  behavior  of  the  object  can  change  while  its  identity  remains  the  same.  For  example,  we  can  specify  a 
set  addition  operation  in  which  the  identical  set  is  both  the  input  and  output.  For  data  structures  with 
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parts,  such  as  instances  of  the  Segment  plan,  mutability  means  that  one  or  more  of  the  parts  may  be 
replaced  while  the  identity  of  the  data  structure  remains  the  same.  For  example,  a  common  operation  on 
Segment  data  structures  is  to  increment  the  Upper  index.  The  semantics  of  mutability  arc  part  of  the 
logical  foundations  of  the  plan  calculus,  which  arc  discussed  later  in  this  section. 

Temporal  plans  specify  computations  whose  parts  are  operations,  tests,  data  structures  or  other 
composite  computations.  In  addition  to  various  logical  constraints  between  roles,  such  as  "less  than  or 
equal”,  temporal  plans  also  include  data  flow  and  control  flow  constraints.  An  example  of  the  temporal 
plan  for  computing  absolute  value  is  shown  in  Fig.  1-2.  Operations  and  tests  are  indicated  in  plan 
diagrams  by  rectangular  boxes.  The  bottom  half  of  test  boxes  are  divided  into  cases  labelled  ”P’  for 
failure  and  ”S”  for  succeed.  This  plan  has  three  roles  named 

If  (a  test  for  less  than  zero). 

Then  (a  negation  operationX  and 
End  (a  join).1 

Data  flow  constraints  (solid  arrows  in  the  figure)  specify  correspondences  between  the  outputs  and 
inputs  of  operations  and  tests.  Control  flow  constraints  (hatched  arrows)  specify  which  parts  of  a 
computation  are  reached  depending  on  which  tests  succeed  or  fail.  Temporal  plans  thus  embody  a  kind 
of  control  abstraction. 

The  plan  calculus  is  to  a  large  degree  programming  language  independent  (for  a  wide  class  of 
conventional  sequential  programming  languages).  This  makes  it  possible  to  build  a  program 
development  system  which  is  concerned  with  the  syntactic  details  of  different  languages  only  at  its  most 
superficial  interface.  In  order  to  translate  back  and  forth  between  a  given  programming  language  and  the 
plan  calculus,  the  primitives  of  the  programming  language  are  divided  into  two  categories: 

(i) The  primitive  actions  and  tests  of  the  language,  such  as  car,  cdr,  cons,  hull  and  el  in 
Lisp,  are  represented  as  input-output  specifications  and  test  specifications. 

(ii) Thc  primitive  connectives,  such  as  prog,  cond,  setq,  go  and  return  Jn  Lisp,  are 
represented  as  patterns  of  control  and  data  flow  constraints  between  operations  and 
tests. 

The  translation  from  standard  program  text  to  an  equivalent  plan  representation  has  been 
implemented  for  reasonable  subsets  of  Lisp  [53],  Fortran  [73]  and  Cobol  [24].  The  translation  from 
suitably  restricted  plans  to  Lisp  code  has  also  been  implemented  by  Waters  [74]. 

Overlays 

Overlays  are  the  mechanism  in  the  plan  calculus  for  representing  points  of  view  in  the 
programming  domain.  An  overlay  is  formally  a  triple  made  up  of  two  plans  and  a  set  of  correspondences 
between  roles  of  the  two  plans.  Each  plan  represents  a  point  of  view;  the  correspondences  express  the 

1.  A  join  is  a  virtual  entity  which  is  needed  in  order  lo  specify  what  the  output  is  in  each  case  of  a  conditional.  Joins  will  be 
defined  in  Chapter  Four. 
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figure  t-2.  A  Temporal  Flan. 
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relationship  between  the  points  of  view.  Overlays  are  similar  to  Sussman’s  "slices”,  which  he  uses  to 
represent  equivalences  in  electronic  circuit  analysis  and  synthesis  [69]. 

In  addition  to  standard  plans,  there  also  standard  overlays.  For  example,,  consider  the  following 
recursive  Lisp  program  which  copies  a  list. 

(DEFINE  COPYLIST 
(LAMBDA  (L) 

(CONO  ((NULL  L)  NIL) 

(T  (CONS  (CAR  L)(COPYLIST  (CDR  L))))))) 

This  program  is  an  example  of  a  singly  recursive  program  in  which  there  is  computation  "on  the 
way  up",  i.e.  in  which  the  recursive  invocation  is  not  the  last  step  in  the  program.  Many  standard 
recursive  computations,  such  as  list  accumulation  by  coNSing,  can  be  performed  either  "on  the  way 
down"  or  "on  the  way  up."  For  example,  die  following  tail  recursive  program,  which  reverses  a  Lisp  list, 
performs  list  accumulation  on  the  way  down. 

(DEFINE  REVERSE 
(LAMBDA  (L) 

(REVERSE1  L  NIL)))) 

(DEFINE  REVERSE  1 
( LAM8DA  (L  M) 

(COND  ((NULL  L)  M) 

(T  (REVERSE1  (CDR  L)(CONS  (CAR  L)  M) ) ) ) ) ) 

Recognition  of  the  standard  Lisp  list  accumulation  plan  in  these  two  programs  is  facilitated  by  an 
overlay  which  expresses  how,  in  general,  to  view  accumulation  on  the  way  up  as  accumulation  the  way 
down  with  an  intervening  order  reversal.  This  overlay  is  shown  in  Fig.  1-3.  Without  going  into  details, 
(For  now,  it  is  adequate  just  to  get  the  idea  that  there  are  plans  on  both  sides  and  correspondences 
between  them.)  consider  that  the  plan  on  the  left  represents  accumulation  on  the  way  up;  the  plan  on  the 
right  represents  accumulation  on  the  way  down.  The  four  hooked  lines  between  the  two  plans  specify 
correspondences  between  the  two  points  of  view.  Unlabelled  correspondences  (three  out  of  the  four  in 
Fig.  1-3)  arc  equalities.  Thus  the  initialization  of  the  accumulation  (the  Init  role)  is  the  same  in  both 
views.  So  are  the  input-output  specifications  of  the  accumulation  operations  (the  Add  role),  and  the  final 
output.  The  most  important  correspondence,  however,  is  the  one  labelled  "reverse"  in  the  figure.  This  is 
the  correspondence  which  specifies  that  the  order  in  which  the  elements  of  list  l  arc  accumulated  in  the 
copylist  program  is  the  reverse  of  the  order  in  which  they  are  generated  by  the  car-cdr  part  of  that 
program.  (The  Lisp  interpreter’s  stack  is  being  used  to  effect  the  reversal.) 

Notice  that  overlays  are  symmetric }  Either  side  can  be  used  as  a  "pattern"  (plans  can  be  naturally 
thought  of  as  patterns),  which  makes  it  possible  to  use  the  same  overlays  in  both  analysis  and  synthesis. 
The  fact  that  correspondences  arc  formally  equalities  means  that  information  can  propagate  between 
points  of  view  in  both  directions.  For  example,  analysis  by  inspection  of  copylist  proceeds  by  first 
recognizing  the  standard  list  accumulation  by  coNSing  plan  in  the  point  of  view  represented  by  the  right 


].  This  is  not  strictly  true,  but  only  For  a  reason  which  ls  beyond  the  level  of  detail  of  this  introduction. 
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Figure  1*3.  An  Overlay. 
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hand  side  of  the  overlay  in  Fig.  1*3.  The  known  properties  of  this  plan  incli'de  the  fact  that  the  final 
output  is  a  list  whose  elements  are  the  successive  inputs  to  the  accumulation  operations,  in  reverse  order. 
Propagating  this  information  back  to  the  original  view  through  the  correspondences  and  performing  the 
algebraic  amplification, 

reverse(reverse(/))=4 

leads  directly  to  the  result  that  the  elements  of  the  output  of  copylist  are  the  same  as  the  elements  of  the 
input  list,  in  the  same  order. 

Implementation  is  also  represented  using  overlays.  One  side  of  such  an  overlay  is  the  plan 
representing  an  abstract  behavior,  e.g.  pushing  an  element  onto  the  front  of  a  queue.  The  other  side  of 
the  overlay  is  an  implementation  plan,  e.g.  storing  the  element  in  an  array  and  adding  one  to  an  index 
pointer.  The  correspondences  in  such  an  overlay  propagate  information  between  the  abstract  and 
concrete  views.  Such  overlays  can  be  used  both  in  analysis  by  inspection  and  in  synthesis  by  inspection. 
In  analysis  by  inspection,  one  tries  to  recognize  known  implementation  plans.  Once  such  a  plan  is 
recognized,  it  is  replaced  by  (overlaid  with)  the  corresponding  abstract  plan,  and  analysis  continues 
similarly,  conversely,  in  synthesis  by  inspection  one  matches  against  abstract  plans  and  instantiates 
implementation  plans. 
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''."be  remaining  features  of  plans  and  overlays,  namely  additivity,  verifiability  and  dependencies,  all 
relate  to  the  logical  foundations  of  the  plan  calculus.  Formally,  a  plan  is  a  set  of  axioms  in  a  first  order 
logic.  (The  details  of  the  axiomatization  are  given  in  Chapter  Eight)  Although  in  fact  plans  are  not 
<n,ended  to  be  manipulated  directly  as  first  order  axioms,  this  logical  foundation  provide  a  semantics  and 
a  set  of  proof  rules  against  which  actual  manipulations  can  be  validated. 

Placing  plans  in  the  paradigm  of  logic  has  several  advantages.  For  example,  additivity  is  a  direct 
consequence  of  an  axiomatic  formalization.  Combining  plans  has  the  same  formal  properties  as  the 
union  of  axiom  systems,  i.e.  the  result  of  combining  two  non-contradictory  plans  is  always  a  plan  which 
satisfies  the  constraints  of  both  of  the  original  plans.  This  is  a  desirable  property  not  shared  by  other 
formalisms,  such  as  program  schemas.  Additivity  also  meshes  well  with  the  principle  of  least 
commitment,  which  in  this  context  means  that  implementation  plans  should  have  the  minimum  number 
of  constraints  necessary  to  support  the  implemented  abstract  behavior. 

The  logical  foundations  of  the  plan  calculus  arc  also  involved  in  inspection  methods  for  program 
verification.  Verification  by  inspection  is  based  on  recognizing  plans  and  applying  already  verified 
overlays.  Automating  the  verification  of  overlays  is  not  part  of  the  research  reported  here.  However,  the 
logical  foundations  developed  here  do  establish  what  needs  to  be  proven  to  verify  an  overlay.  For 
example,  the  verification  of  an  implementation  overlay  entails  proving  that  the  constraints  of  the  abstract 
plan  are  derivable  from  the  constraints  of  the  implementation  plan  together  with  the  correspondences 
taken  as  premises. 
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In  addition  to  simply  recording  that  an  overlay  has  been  verified,  it  is  useful  to  keep  a  record  of 
which  constraints  of  the  implementation  plan  were  used  in  the  proof  of  which  constraints  of  the  abstract 
plan.  This  information  can  be  extracted  as  a  by-product  of  the  proof  process  [64],  Such  links  are  called 
dependencies.  Dependencies,  as  part  of  the  plan  calculus,  are  a  network  of  links  between  specifications 
which  trace  the  logical  derivation  of  one  from  the  other.  Dependencies  capture  a  dimension  of  logical 
structure  which  is  different  from  the  hierarchical  decomposition  expressed  by  die  roles  of  a  plan. 

Dependencies  make  it  possible  for  the  programmer’s  apprentice  to  explain  how  a  program  works 
and  reason  about  the  potential  effects  of  a  modification.  For  example,  if  you  want  to  delete  a  constraint 
from  an  implementation  plan,  the  dependencies  tell  you  exactly  which  constraints  of  the  corresponding 
abstract  plan  could  become  invalid.  Similarly,  if  you  change  the  abstract  specifications  of  an  already 
verified  overlay,  the  dependencies  indicate  which  parts  of  the  verification  need  to  be  redone  and  which 
parts  can  be  carried  over  without  any  extra  work.  The  use  of  dependencies  in  reasoning  about  programs, 
especially  in  program  evolution  and  modification,  has  been  the  focus  of  related  work  by  Shrobe  [64], 

1.4  Guide  to  the  Reader 

The  remaining  chapters  of  this  report  can  be  grouped  into  three  units.  The  first  unit,  consisting  of 
Chapters  Two,  Three  and  Four,  gives  an  overview  of  the  three  main  areas  of  this  work.  Chapter  Two  is  a 
scenario  which  illustrates  the  use  of  inspection  methods  in  understanding  an  example  program  which 
implements  a  simple  symbol  table  with  hashing.  Chapter  Three  outlines  the  scope  of  the  current  plan 
library'.  Chapter  Four  introduces  the  diagrammatic  notation  which  will  be  used  in  the  rest  of  the  report  to 
define  plans  and  overlays. 

Chapters  Five,  Six  and  Seven  form  a  second  unit,  which  fills  in  more  details.  Each  of  these  chapters 
is  an  in-depth  scenario  of  the  use  of  inspection  methods  in  program  analysis,  synthesis  or  verification. 
The  example  program  introduced  in  Chapter  Two  is  also  used  in  each  of  these  chapters.  The  style  of 
presentation  in  these  chapters  is  to  introduce  and  explain  new  plans  as  they  are  needed  in  the  example. 
Also,  for  ease  of  referring  to  previously  defined  plans,  an  index  is  provided  at  the  back.  If  there  are  two 
page  numbers  listed  for  each  item,  the  first  is  the  page  on  which  the  plan  or  overlay  diagram  appears;  the 
second  is  the  appendix  entry  for  that  item. 

The  final  unit.  Chapters  Eight,  Nine  and  the  appendix,  is  the  most  detailed  and  technical.  Chapter 
Eight  lays  out  the  logical  foundations  of  plans  and  overlays,  including  the  formalization  of  plans  involving 
side  effects.  Chapter  Nine  gives  the  detailed  formalization  of  loop  plans  and  temporal  abstraction  (a  way 
of  viewing  loops  in  which  their  specifications  are  easily  composed).  These  topics  arc  treated  in  a  more 
general  way  earlier.  The  appendix  is  a  reference  for  the  plan  library,  in  which  can  be  found  the  detailed 
specifications  for  any  plans  or  overlays  not  fully  described  in  the  text 

1.5  Relation  to  Other  Work 

It  is  useful  to  distinguish  three  areas  of  concern  in  this  work.  In  this  section  1  outline  some 
connections  and  comparisons  with  other  work  in  these  areas.  The  three  areas  are: 
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*  Taxonomy  -  Standard  programming  forms  and  the  relationships 

between  them. 

*  Formalism  -  For  representing  programming  knowledge. 

*  Applications  -  Analysis,  synthesis,  and  verification  of  programs. 

More  generally,  at  the  end  of  this  section,  I  discuss  related  work  on  aspects  of  programming  other 
than  the  use  of  inspection  methods,  such  as  debugging  and  deductive  methods. 

Program  Taxonomies 

Many  people  in  the  computer  science  and  software  engineering  community  have  been  calling  for 
the  codification  of  standard  program  forms  for  a  long  time.  Two  major  motivations  for  this  are:  to 
improve  software  reliability  and  correctness,  and  to  improve  the  education  of  programmers.  For 
example,  Dijkstra  in  his  influential  Notes  on  Structured  Programming  [17]  called  for  the  codification  of 
standard  program  forms  with  associated  theorems  about  their  correctness,  as  follows.1 

V:=D; 

while  non  prop (d)  do  d :  =  /(d)"  (6) 

When  a  programmer  considers  a  construction  like  (6)  as  obviously  correct,  he  can  do 
so  because  he  is  familiar  with  the  construction.  1  prefer  to  regard  his  behavior  as  an 
unconscious  appeal  to  a  theorem  he  knows,  although  perhaps  he  has  never  bothered  to 
formulate  it;  and  once  in  his  life  he  has  convinced  himself  of  its  truth,  although  he  has 
probably  forgotten  in  which  way  he  did  it  and  although  the  way  was  (probably)  unfit 
for  print.  But  we  could  call  our  assertions  about  program  (6),  say,  "The  Linear  Search 
Theorem”  and  knowing  such  a  name  it  is  much  easier  (and  more  natural)  to  appeal  to 
consciously. 

...it  might  be  a  useful  activity  to  look  for  a  body  of  theorems  pertinent  to  such 
programs. 

More  recently,  Floyd  in  his  1978  ACM  Turing  Award  Lecture  [27]  spoke  as  follows  about  die 
importance  of  teaching  the  standard  forms  of  programming  to  new  programmers,  as  compared  with 
emphasizing  the  primitive  programming  language  constructs.  (Floyd  calls  these  forms  paradigms  and  is 
particularly  interested  in  very  general  ones,  such  as  "divide  and  conquer").2 

To  the  teacher  of  programming,  even  more,  I  say:  identify  the  paradigms  you  use,  as 
fully  as  you  can,  then  teach  them  explicitly.  They  will  serve  your  students  when  Fortran 
has  replaced  Latin  and  Sanskrit  as  the  archetypal  dead  language. 


1.  p.  10. 

1  p.459. 
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Many  people  have  answered  these  calls,  using  a  variety  of  expressive  tools  and  covering  a  range  of 
programming  ^reas.  1  group  these  efforts  roughly  into  two  categories. 

In  the  first  category  are  those  who  have  tried  to  give  wide  coverage  of  the  basic  forms  of  everyday 
programming,  such  as  the  standard  manipulations  involving  of  sets,  directed  graphs  and  linear  data 
structures  (lists  dpd  sequences).  Most  prominent  in  this  category  is  the  work  of  Knuth  [37].  In  three 
volumes,  Knuth  uses  a  mixture  of  mathematics,  example  programs  and  expository  English  text  to 
communicate  his  "programmer’s  craft"  in  fundamental  algorithms  (manipulations  on  linear  lists  and 
trees),  semi-numerical  algorithms  (random  numbers  and  arithmetic),  sorting  and  searching.  There  are 
also  many  one-volume  text  books  [1]  which  have  a  similar  format,  but  are  less  comprehensive. 

In  the  second  category,  I  put  those  whose  have  focused  on  a  more  particular  programming  domain. 
Not  surprisingly,  work  in  this  category  is  also  characterized  by  more  formal  representations  (some  of 
which  will  be  discussed  in  the  next  section).  Domains  that  have  been  studied  in  some  depth  include 
algorithms  on  sequences  [50.52],  sorting  [32],  standard  loop  forms  [49,73],  set  implementations  [61,57], 
and  the  implementation  of  associative  data  structures  [58]. 

This  work  falls  partly  in  both  categories.  The  contents  of  the  current  plan  library  is  mostly  the 
result  of  generalizing  the  plans  required  for  an  in-depth  understanding  of  a  particular  example  program 
—  the  implementation  of  a  symbol  table  using  hashing,  which  is  introduced  in  the  scenario  in  Chapter 
Two.  This  example  program  was  chosen  because  it  involves  many  different  techniques  which  are 
representative  of  the  domain  of  routine  symbolic  manipulations  (sets,  lists,  etc.).  I  believe  that  a  library 
which  is  adequate  for  this  example  is  a  good  start  towards  complete  coverage  of  the  domain.  The  small 
fraction  of  plans  in  the  current  library  which  are  not  directly  motivated  by  the  symbol  table  example  fall 
into  two  categories.  Some  of  these  are  obviously  important  basic  plans  which  don’t  happen  to  be  used  in 
the  example,  such  as  counting  and  accumulation  loops.  Other  plans  are  included  to  fill  gaps  in  the 
taxonomic  structure  of  the  library,  such  as  the  plan  for  splicing  into  a  list  (only  splicing  out  appears  in  this 
particular  symbol  table).  Barstow’s  work  [6]  is  similar  in  depth  and  breadth. 

Other  Formalisms 

Past  efforts  to  construct  knowledge  bases  for  automatic  or  partially  automated  programming  have 
used  the  following  formalisms:  program  schemas  [29],  program  transformations  [15,5,12],  program 
refinement  rules  [6],  and  formal  grammars  [59].  Although  each  of  these  representations  has  been  found 
useful  in  certain  applications,  none  combines  alt  of  the  important  features  of  the  plan  calculus  listed 
above. 

For  example,  program  schemas  (incomplete  program  texts  with  constraints  on  the  unfilled  parts) 
have  been  used  by  Wirth  [76]  to  catalog  programs  based  on  recurrence  relations,  by  Basu  and  Misra  [7]  to 
represent  typical  loops  for  which  the  loop  invariant  is  already  known,  and  by  Gerhart  [29]  and  Misra  [50] 
to  represent  and  prove  the  properties  of  various  other  common  forms.  Unfortunately,  the  syntax  of 
conventional  programming  languages  is  not  well  suited  for  the  kind  of  generalization  needed  in  this 
endeavor.  For  example,  the  idea  of  a  search  loop  (a  standard  programming  form)  expressed  informally 
in  English  should  be  something  like  the  following. 
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A  search  loop  is  a  loop  with  two  exits  in  which  a  given  predicate  (the  same  one 
each  time)  is  applied  to  a  succession  of  objects  until  either  the  predicate  is 
satisfied,  in  which  case  that  object  is  made  available  for  use  outside  the  loop,  or 
the  objects  to  be  searched  are  exhausted. 

In  Lisp,  as  in  other  languages,  this  kind  of  loop  can  be  written  in  innumerable  forms,  many  of 
which  are  syntactically  (and  structurally)  very  different,  such  as: 

( PROG  () 

lp  (cono  ( exhausted  (return  nil))) 

(coho  (( predicate  current)  (Rtumu  current))) 

(60  LP)) 

or  with  only  (me  return  instead  of  two, 

(PR06  () 

lp  (CONO  (exhausted  NIL) 

(T  ... 

(COND  (( predicate  current) 

(return  current)',) 

(GO  LP)))) 

or  even  recursively,  tg. 

(DEFINE  SEARCH  () 

(CONO  ( exhausted  NIL) 

(T  ... 

(COND  ((predicate  current)  current) 

(T  ... 

(SEARCH)))))) 

The  problem  here  is  that  conventional  programming  languages  are  oriented  towards  specifying 
computations  in  enough  detail  so  that  a  simple  local  interpreter  cap  carry  them  out  Unfortunately  a  lot 
of  this  detail  is  often  arbitrary  and  conceptually  unimportant  In  the  plan  calculus,  all  three  of  the 
schemas  above  (and  many  other  such  variations)  are  expressed  by  a  single  plan. 

A  new  generation  of  programming  languages  descended  from  Simula  [16],  such  as  CLU  [38]  and 
Alphard  [77],  provide  a  syntax  for  specifying  standard  forms  such  as  the  search  loop  in  a  more  canonical 
way.  However,  there  are  two  more  fundamental  difficulties  with  using  program  schemas  to  represent 
standard  program  forms,  which  Simula  and  its  descendants  do  not  solve.  First,  programs  (and  therefore 
program  schemas)  arc  not  in  general  easy  to  combine,  nor  are  they  additive.  This  means  that  when  you 
combine  two  program  schemas,  the  resulting  schema  is  not  guaranteed  to  satisfy  the  constraints  of  both  of 
the  original  schemas,  due  to  such  factors  as  destructive  interactions  between  variable  assignments. 
Second,  existing  programming  languages  do  not  allow  multiple  views  of  the  same  program  or  overlapping 
module  hierarchies.  I  believe  the  reason  for  this  is  that  a  program  is  still  basically  thought  of,  from  the 
standpoint  of  these  languages,  as  a  set  of  instructions  to  be  executed,  rather  than  as  a  set  of  descriptions 
(e.g.  blueprints)  which  together  specify  a  computation. 


/ 
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Another  commonly  used  formalism  for  representing  abstract  programming  forms  is  flowchart 
schemas.  Originally  developed  by  lanov  in  1960  [36],  flowchart  schemas  are  a  network-like  connection  of 
test  and  operation  boxes.  This  formalism  has  the  features  of  being  programming  language  independent 
and  having  logical  foundations.  (Manna  gives  an  excellent  tutorial  on  the  formalization  and  use  of 
flowchart  schemas  in  his  book  on  the  mathematical  theory  of  computation  [40].)  Flowchart  schemas 
capture  control  flow  abstraction  in  a  very  natural  and  intuitive  way.  However,  the  only  method  they 
provide  for  expressing  the  flow  of  data  between  operations  is  variable  assignment.  Unfortunately,  the  use 
of  variables  in  this  way  destroys  additivity  the  same  as  for  programming  languages. 

This  problem  with  flowchart  schemas  can  be  fixed  by  combining  flowchart  schemas  with  another 
network-like  formalism,  the  data  flow  schemas  of  Dennis  [19],  In  data  flow  schemas,  operations  have  local 
port  names  and  data  flow  is  represented  by  port-to-port  connections.  The  synthesis  of  these  two  types  of 
schemas  is  essentially  the  temporal  plan  formalism  used  here.  Temporal  plans,  however,  have  the 
additional  feature  that  mutable  objects  are  representable,  which  is  not  the  case  in  data  flow  schemas. 

A  currently  popular  approach  for  specifying  data  abstractions  is  the  algebraic  axiom 
formalism  [33,39,30].  Though  data  plans  are  formally  equivalent  to  abstract  data  types,  in  practice  the 
approach  in  this  work  is  somewhat  different  (mostly  due  to  concern  with  mutable  objects).  In  the 
algebraic  axiom  framework,  there  are  no  mutable  objects  or  side  effects.  For  example,  in  the  standard 
algebraic  axiomatization  of  stacks  one  defines  the  following  three  primitive  functions  on  stacks1 

push :  stack  X  object  -*•  stack 
pop :  stack  -*  stack 
top:  stack  -*  object 

and  the  following  set  of  algebraic  equations. 

top(push(x^))=y 
pop(push(ar,y))  =  x 

In  this  work,  however,  similar  behavior  is  formalized  differently.  The  only  primitive  functions  on  a 
data  structure  are  its  roles,  which  are  thought  of  as  access  functions.  For  example,  the  fundamental  singly 
recursive  data  structure  is  called  List.  The  two  primitive  access  functions  on  lists  are2 

head:  list -*■  object 
tail:  list  -*  list 

In  this  framework,  operations  such  as  Push,  Pop,  and  Top,  arc  non-primitive  concepts  which  are 
specified  by  input-output  specifications  roughly  as  follows. 

(i)  A  Push  operation  take  as  input  a  list  and  an  object;  its  output  is  a  list  whose  head  is  the 
input  object  and  whose  tail  is  the  input  list. 


1.  We  do  not  worry  about  the  empty  stack  in  this  example. 

2.  Again  we  do  not  worry  about  the  empty  case,  since  it  is  not  relevant  to  the  comparison  being  made  in  this  section.  The 
formalization  of  data  plans  is  presented  more  completely  in  Chapter  Eight 
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(ii)  A  Pop  operation  takes  as  input  a  list;  its  output  is  the  tail  of  the  input  list 

(iii)  A  Top  operation  takes  as  input  a  list;  its  output  is  the  head  of  the  input  list 

Side  effects  are  specified  in  this  framework  by  specifying  an  operation  ir.  which  the  same  object  is 
both  input  and  output,  but  in  which  parts  of  that  object  (i.e  the  values  of  primitive  access  functions)  are 
different  before  and  after.  Recently,  Guttag  and  Homing  {34]  have  taken  a  similar  approach.  They  call 
the  part  of  their  system  in  which  side  effects  arc  specified  "routines"  and  use  the  predicate  transformer 
notation  instead  of  preconditions  and  postconditions. 

Other  work  on  representing  mutable  data  objects  and  side  effects  includes  Early  [23],  Burstall  [11] 
and  Yonezawa  [78].  Of  these,  the  V-graphs  of  Early  are  the  most  similar  to  data  plans.  Early  also  takes 
access  paths  as  the  only  primitive  functions,  and  specifies  side  effect  operations  as  transformations  on  the 
part  structure  of  data  objects. 

Currently  the  most  common  way  to  represent  relationships  between  standard  forms  (typically 
implementation/abstraction  relationships)  is  via  program  transformations  or  program  refinement 
rules  [6].  As  compared  to  overlays,  these  formalisms  have  two  serious  problems  which  stem  from  their 
lack  of  neutralness  between  analysis  and  synthesis.  An  overlay  in  the  plan  calculus,  as  in  Fig.  1-4,  is  made 
up  of  two  plans  and  a  set  of  correspondences  between  the  parts  of  the  two  plans.  Each  plan  represents  a 
point  of  view;  the  correspondences  express  the  relationship  between  the  points  of  view.  For  example,  in 
an  implementation  overlay  the  plan  on  the  right  hand  side  is  the  abstract  description  and  the  plan  on  the 
left  hand  side  is  an  implementation.  It  is  important,  however,  that  either  plan  can  be  used  as  the 
"pattern".  In  a  typical  program  synthesis  step  using  overlays  the  right  hand  plan  is  used  as  the  pattern 
and  the  left  hand  plan  is  instantiated  as  a  further  implementation.  Conversely,  in  a  typical  analysis  step, 
the  left  hand  plan  serves  as  the  pattern  and  the  right  hand  plan  is  instantiated  as  a  more  abstract 
description.  With  both  program  refinement  rules  and  knowledge-based1  program  transformations  this 
sort  of  symmetric  use  is  not  possible  since  the  right  hand  side  of  a  transformation  or  refinement  rule  is 
typically  a  sequence  of  substitutions  or  modifications  to  be  performed,  rather  than  a  pattern. 

A  second  problem  stemming  from  the  asymmetry  of  tran;>-_<n'ations  and  refinement  rules 

is  their  lack  of  verifiability.  The  correctness  of  an  overlay  in  the  plan  calculus  is  verified  by  proving 
essentially  that  the  constraints  of  the  plan  on  the  left  hand  side,  together  with  the  correspondences  (which 
are  formally  a  set  of  equalities  between  terms  on  the  left  and  terms  on  the  right)  imply  the  constraints  of 
the  plan  on  the  right  hand  side.  Neither  Balzcr’s  transformation  language  nor  Green  and  Barstow’s 
refinement  tree  notation  has  been  adequately  formalized  to  permit  the  question  of  correctness  to  be 
addressed.  The  recent  work  of  Broy  and  Pepper  [10]  is  an  improvement  in  this  direction,  since  their 
transformations  have  program  forms  on  both  the  left  and  right  hand  sides,  with  associated  proof  rules. 
Unfortunately,  they  use  program  schemas  as  the  representation  of  the  standard  forms  which  has  the 
difficulties  discussed  above. 


1.  As  opposed  to  the  folding-unfolding  and  similar  transformations  of  Burstall  and  Darlington  [12]  which  are  intended  to  be  a 
small  set  of  very  general  transformations  which  are  formally  adequate,  but  which  must  be  composed  appropriately  to  construct 
intuitively  meaningful  implementation  steps. 
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Another  formalism  some  have  found  attractive  for  codifying  programming  knowledge  is  formal 
grammars.  For  example,  Ruth  [59]  constructed  a  grammar  (with  global  switches  to  control  conditional 
expansions)  which  represented  the  class  of  programs  expected  to  be  handed  as  exercises  in  an 
introductory  PL/1  programming  class.  This  grammar  was  used  in  a  combination  of  top-down,  bottom-up 
and  heuristic  parsing  techniques  in  order  to  recognize  correct  and  near-correct  programs.  Miller  and 
Goldstein  [47]  also  used  a  grammar  formalism  (implemented  as  an  augmented  transition  network)  to 
represent  classes  of  programs  in  a  domain  of  graphical  programming  with  stick  figures.  The  major 
shortcoming  of  these  grammars  from  the  point  of  view  of  the  programmer's  apprentice  is  their  lack  of  a 
clear  semantics  upon  which  a  verification  methodology  can  be  based. 

Computer  Aided  Program  Development  Systems 

The  application  area  to  which  this  work  is  aimed  can  be  generally  described  as  computer  aided 
environments  for  program  development  In  particular,  this  work  is  part  of  a  project  [56]  aimed  at 
developing  what  we  call  a  programmer’s  apprentice  system.  What  distinguishes  a  programmer’s 
apprentice  from  existing  systems  is  the  level  of  program  understanding  shared  between  the  user  and  the 
system. 

Existing  program  development  systems  provide  various  types  of  services  at  different  levels  of 
understanding.  The  level  of  least  understanding  is  when  the  system  manipulates  everything  as  text 
strings.  At  this  level,  various  kinds  of  useful  bookkeeping  can  be  provided,  such  as  keeping  track  of 
versions  of  source  code,  test  data  and  documentation  [2,22]. 

The  next  level  of  understanding  is  when  the  system  is  able  to  parse  the  syntax  of  the  user’s 
programming  language.  At  this  level  it  is  possible  to  provide  many  more  useful  services,  such  as  structure 
editors  ]20]  and  cross-referencing  [70].  If  in  addition  the  system  can  interpret  the  semantics  of  the 
programming  language,  then  further  analysis  and  verification  assistance  is  possible,  such  as  symbolic 
interpreters  [13,3]  and  verification  condition  generators  [51].  A  slight  step  above  the  programming 
language  understanding  level  are  systems  which  support  the  syntax  of  a  more  abstract  design 
formalism  [75]. 

1  believe  that  current  systems  are  quickly  approaching  fundamental  limitations  to  the  services  they 
can  provide  due  to  fact  that  they  understand  programs  only  at  the  level  of  the  programming  language.  I 
believe  the  next  major  step,  represented  by  the  programmer’s  apprentice,  is  to  understanding  based  on  a 
library  of  standard  programming  forms.  This  will  make  it  possible  for  the  system  to  apply  inspection 
methods  to  the  analysis,  synthesis  and  verification  of  programs.  The  scenario  in  the  next  chapter 
elaborates  what  a  programmer's  apprentice  could  do. 

Other  Aspects  Of  Programming 

Inspection  methods  are  certainly  not  the  whole  story  in  programming.  Programmers  are  not  always 
faced  with  totally  familiar  problems.  Miller  [48]  has  studied  and  catalogued  some  very  general  problem 
decomposition  methods  which  programmers  can  apply  when  faced  with  unfamiliar  problems. 
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Sussman  [67]  has  explored  the  role  of  debugging  when  plans  are  "almost  right".  Finally,  Manna  and 
Waldinger  [41]  have  explored  the  applicability  of  deductive  methods  to  programming. 

Other  Engineering  Problem  Solving 

The  study  of  problem  solving  in  other  areas  of  engineering  has  had  a  strong  influence  on  this  work. 
In  particular,  the  notion  of  the  plan  for  a  program  is  similar  to  the  plans  for  electrical  circuits  in  the  work 

of  Brown  [9]  and  de  Kleer  [18].  Freiling  [28]  also  used  a  similar  approach  in  the  area  of  mechanical 
engineering. 
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CHAPTER  TWO 

PROGRAMMER’S  APPRENTICE  SCENARIO 


2.1  Introduction 

A  library  of  plans  opens  up  many  new  possibilities  for  what  a  computer  aided  program 
development  system  can  do  to  help  a  programmer.  This  chapter  illustrates  some  of  these  new 
possibilities,  without  going  into  too  much  detail.  Chapters  Five,  Six  and  Seven  go  into  more  depth  on 
how  the  behavior  illustrated  here  can  be  implemented. 

Many  different  activities  are  interwoven  in  the  programming  process.  These  activities  can  be 
roughly  dividing  into  three  major  areas:  analysis,  synthesis  and  verification.  Analysis  activities  in  general 
involve  determining  properties  of  a  program  which  arc  not  explicit  in  its  definition  (usually  by 
decomposing  it  into  parts).  Synthesis  in  general  involves  refining  an  abstract  description  into  one  which 
is  more  detailed  in  the  appropriate  sense  for  some  target  machine.  Verification  in  general  has  to  do  with 
detecting  errors  and  constructing  arguments  as  to  why  a  program  works. 

A  program  development  system  can  aid  a  programmer  in  all  three  of  these  areas.  For  a 
programmer’s  apprentice  system,  in  particular,  this  means  the  same  library  of  plans  is  used  for  analysis, 
synthesis  and  verification  by  inspection.  For  example,  suppose  there  is  a  plan  which  captures  the  idea  of 
iteration  with  a  "trailing"  value,  as  illustrated  by  the  following  code. 

(PROG  (CURRENT  PREVIOUS) 

IP  (SETQ  CURRENT  ...) 

(SETQ  PREVIOUS  CURRENT) 

(GO  LP)) 

If  this  plan  is  in  the  library,  the  system  should  be  able  to  recognize  its  use  in  programs  it  hasn’t  seen 
before:  it  should  be  able  to  synthesize  programs  using  this  plan;  and  it  should  be  able  to  detect  errors  in 
the  use  of  this  plan,  such  as  incorrect  initialization.  This  factorization  of  knowledge  is  an  important 
feature  of  the  design  of  programmer’s  apprentice. 

The  scenario  in  this  chapter  portrays  a  system  in  which  inspection  methods  for  program  analysis, 
synthesis  and  verification  arc  fully  integrated.  At  the  time  of  this  writing,  an  integrated  system  with  these 
capabilities  has  not  yet  been  implemented.  However,  several  of  the  major  functions  portrayed  in  the 
scenario  have  been  implemented  separately  in  experimental  form.  Waters  has  implemented  a  system 
which  translates  Lisp  code  to  the  plan  calculus  and  performs  some  further  analysis  on  the  resulting  plans. 
Shrobe  has  implemented  a  system  which  verifies  plans  by  symbolic  evaluation.  Although  a  complete 
synthesis  system  has  yet  been  implemented.  Waters  has  implemented  the  bottom-end  module  for  this 
which  translates  suitably  detailed  plans  to  Lisp  code.  Finally,  an  experimental  program  for  automatically 
drawing  plan  diagrams  from  the  system's  internal  representation  has  also  been  implemented. 
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What  we  will  see  in  this  scenario  is  basically  the  top-down,  stepwise  refinement  style  of  program 
development.  This  should  not  be  taken  as  an  endorsement  of  this  methodology  to  the  exclusion  of  all 
others.  I  believe  that  the  appropriate  style  of  development  depends  greatly  on  the  particular 
programming  task.  A  strongly  top-down  development,  such  as  in  this  scenario,  is  appropriate  when  the 
programming  task  is  very  familiar.  On  other  occasions,  a  bottom-up  or  middle-out  methodology  may  be 
more  appropriate.  This  research  is  aimed  at  developing  the  representations  and  basic  capabilities  which 
are  needed  to  support  program  development  in  any  order. 

2.2  The  Scenario 

In  this  scenario,  we  see  an  expert  user  interacting  with  a  programmer’s  apprentice  system  to  develop 
the  implementation  of  a  symbol  table  using  hashing.  Lines  typed  by  the  user  are  in  lower  case;  lines 
typed  by  the  system  are  in  upper  case.  The  user  communicates  with  the  system  in  a  simple  English-like 
command  language.  The  important  part  of  this  language  is  not  its  syntax,  but  the  vocabulary  of 
programming  terms  shared  between  the  user  and  the  system. 

>  let  a  "symbol  tablo"  bo  a  finite  sot. 

OK 

The  system  initially  doesn’t  know  anything  about  symbol  tables  per  se.  The  user  thus  begins  by 
introducing  "symbol  table”  as  a  new  term  (indicated  by  quotation  marks).  The  term  finite  set  is  known  to 
the  system. 

>  Implement  a  symbol  tablo. 

APPLICABLE  IMPLEMENTATIONS  FOR:  SYMBOL-TABLE  (A  FINITE-SET) 

1.  LIST 

2.  SEQUENCE 

3.  LABELLED-THREAD 

4.  DISCRIMINATION 

»  i 

Here  the  system  presents  a  menu  of  ways  it  knows  for  implementing  a  finite  set  A  completely 
menu-driven  scenario  is  shown  in  Chapter  Six.  Such  menus  are  computed  dynamically  by  searching  the 
current  library  for  overlays  between  finite  sets  and  other  data  structures.  At  present  there  are  only  four 
choices;  more  implementations  will  be  added  to  the  library  in  the  future.  The  user  declines  to  choose  an 
option,  asking  for  some  documentation  first 

>  describe  a  discrimination  function. 

A  DISCRIMINATION  FUNCTION  IS  A  FUNCTION  FROM  OBJECTS  TO  SETS 

SUCH  THAT.  IF  AN  OBJECTS  IS  IN  A  SET  IN  THE  RANGE  OF  THE  FUNCTIQN, 

THEN  THE  FUNCTION  APPLIED  TO  THE  OBJECT  EQUALS  THE  SET. 


>  implement  a  symbol  table  as  a  discrimination  function. 
OK 
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A  discrimination  function  is  a  function  which  partitions  its  domain  into  a  disjoint  set  of  sets  (called 
buckets).  Discrimination  functions  are  part  of  the  system’s  library  of  standard  forms.  The  formal 
definition  of  discrimination  (unction  presented  above  is  not  a  "canned"  text  string,,  but  is  constructed 
from  the  logical  formula  which  defines  discrimination  function  in  the  system’s  library.1  The  user’s  first 
refinement  step  is  then  to  implement  the  symbol  table  as  a  discrimination  function. 

The  library  also  contains  plans  and  overlays  involving  discrimination  functions.  The  overlay 
invoked  by  the  user  above  says  that  a  discrimination  function  can  be  viewed  as  implementing  a  set  which 
is  the  union  of  its  buckets. 

>  sho»  code  for  addition  to  a  symbol  table  by  side  effect. 

(DEFINE  SYMBOL- TABLE -AOO 

(LAMBDA  (OLD  INPUT)  ;MODIFIES  OLD. 

(PROG  (BUCKET) 

( SET Q  BUCKET  (APPLY  OLD  INPUT)) 

(UPDATE-FUNCTION  OLD 

BUCKET 

(BUCKET-ADD  BUCKET  INPUT))))) 

(DEFINE  BUCKET-ADO 
(LAMBDA  (OLD  INPUT) 

...)) 

(DEFINE  UPOATE- FUNCTION 

(LAMBDA  (OLD  VALUE  INPUT)  ;MODIFIES  OLD. 

...)) 

The  system  knows  how  to  implement  addition  to  a  set  implemented  as  a  discrimination  function. 
One  way  of  displaying  this  knowledge  is  for  the  system  to  generate  code  from  its  current  plan 
representation  of  the  design  thus  far.  As  can  be  seen  above,  this  code  has  gaps  in  it  (indicated  by  three 
dots).  These  gaps  correspond  to  the  fact  that  it  doesn’t  yet  know  how  the  discrimination  function  or  the 
buckets  arc  implemented. 

The  arguments  to  the  procedure  symbol -table -add  are  the  symbol  table  to  be  modified  (old)  and 
the  entry  to  be  added  (input).  At  this  point  in  the  design,  all  the  system  knows  is  that  the  old  symbol 
table  is  a  function,  but  not  how  that  function  is  implemented.  The  discrimination  function  may  later  in 
the  design  turn  out  to  be  implemented  by  a  Lisp  procedure,  by  a  data  structure,  or  by  a  combination  of 
the  two.  The  code  (apply  old  input)  in  the  first  line  of  symbol-table-add  is  therefore  used  by  the 
system  to  express  the  general  idea  of  applying  the  discrimination  function  to  get  the  appropriate  bucket  in 
which  to  add  the  given  entry.  Similarly,  the  procedure  update- function  is  a  placeholder  for  the 
operation  of  modifying  an  old  function  such  that  all  domain  elements  which  used  to  map  to  a  given  range 
value  (in  this  case  the  bucket  before  addition),  will  afterwards  map  to  the  input  (in  this  case  the  bucket 
after  addition). . 


1.  See  the  appendix  For  the  definition  in  logical  form.  The  technology  for  malting  this  kind  of  a  straightforward  translation 
exists  (46). 
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Despite  the  arguments  made  earlier  as  to  why  code  is  not  an  appropriate  internal  representation  for 
the  library  of  standard  forms,  code  can  still  be  a  convenient  language  for  communicating  between  the 
system  and  the  user  in  certain  circumstances.  Also  code  has  the  advantage  of  being  more  familiar  to  the 
user  than  the  plan  calculus.  Notice  also  that  the  system  has  annotated  the  code  it  has  written  with 
comments.  We  will  see  later  in  the  scenario  that  the  system  also  reads  the  comments  on  any  code  that  the 
user  types  in. 


>  describe  symbol -table-add. 

SET  ADDITION  TO  A  DISCRIMINATION  FUNCTION  IS  IMPLEMENTED  BY  THREE  STEPS  -- 
DISCRIMINATE:  APPLY  THE  DISCRIMINATION  FUNCTION, 

ACTION:  SET  ADDITION, 

UPDATE:  MODIFY  THE  DISCRIMINATION  FUNCTION  WITH  A  NEW  VALUE. 

SUCH  THAT 

THE  OUTPUT  OF  THE  DISCRIMINATE  STEP  IS  THE  OLD  SET  OF  THE  ACTION  STEP; 

THE  INPUT  OBJECT  OF  THE  ACTION  IS  THE  INPUT  OBJECT  OF  THE  DISCRIMINATE  STEP; 

THE  OUTPUT  OF  THE  DISCRIMINATE  STEP  IS  THE  VALUE  INPUT  TO  THE  UPDATE  STEP; 

THE  NEW  SET  OF  THE  ACTION  STEP  IS  THE  INPUT  OBJECT  TO  THE  UPDATE  STEP; 

AND  THE  DISCRIMINATION  FUNCTION  IS  THE  OLD  FUNCTION  INPUT  TO  THE  UPDATE  STEP. 


In  response  to  a  request  from  the  user,  the  system  here  gives  a  toplcvcl  logical  decomposition  of  the 
code  it  has  written.  This  description  is  again  not  "canned"  text,  but  can  be  generated  from  the  plan 
representation  as  needed.  For  this  sort  of  information,  displaying  the  plan  diagram  shown  in  Fig.  2-1  is 
probably  superior. 

>  Imploment  the  discrimination  function  as  a  keyed  discrimination. 

OK 

>  describe  keyed  discrimination, 

A  KEYED  DISCRIMINATION  IS  A  COMPOSITION  OF  TWO  FUNCTIONS  — 

ONE:  A  FUNCTION  ("THE  KEY  FUNCTION’), 

TWO:  A  FUNCTION  ("THE  BUCKET  FUNCTION"), 

SUCH  THAT  THE  COMPOSITION.  VIEWED  AS  A  FUNCTION.  IS  A  DISCRIMINATION 
.  FUNCTION. 

The  design  of  the  symbol  table  continues  in  small  steps.  The  next  step  here  is  to  decompose  the 
discrimination  function  into  two  functions:  one  which  maps  from  objects  to  keys:  and  one  that  maps  from 
keys  to  buckets.  The  strings  in  quotation  marks  above  are  "canned”  text  which  is  attached  to  roles  of  the 
plan  to  give  better  words  than  "the  one  function"  and  "the  two  function",  which  would  be  generated 
automatically. 

The  system  knows  quite  a  bit  about  functional  compositions.  For  example,  it  knows  that  the  range 
of  the  first  function  must  be  a  subset  of  the  domain  of  the  second  function.  It  also  knows  that  to  update  a 
function  implemented  as  the  composition  of  two  functions,  it  suffices  to  update  the  second  function. 
Both  of  these  pieces  of  information  will  be  used  later  in  the  scenario. 
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Figure  2*1.  Discriminate,  Action  and  Update  Plan  for  Addition  to  Symbol  Table. 
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>  the  key  function  of  the  keyed  discrimination  Is  car. 

Ok 

>  Implement  the  bucket  function  of  the  keyed  discrimination  as  a  hashing. 
Ok 

>  describe  hashing. 

A  HASHING  IS  A  COMPOSITION  OF  TWO  FUNCTIONS  — 

ONE:  A  FUNCTION  ('THE  HASH  FUNCTION*). 

TWO:  AN  IRREDUNDANT  SEQUENCE  ('THE  TABLE*)  . 


The  final  step  in  the  refinement  of  the  symbol  table  data  structure  is  to  introduce  hashing.  The 
basic  idea  of  hashing  is  to  decompose  a  function  (in  this  case  the  function  from  keys  to  buckets)  into  two 
functions:  a  many-to-onc  function  which  maps  from  the  domain  of  the  original  function  to  an  initial 
interval  of  the  natural  numbers;  and  a  one-to-one  function  which  maps  from  the  natural  numbers  to  the 
range  of  the  original  function.  (Sequences  are  formalized  in  this  system  as  functions  on  initial  intervals  of 
the  natural  numbers.  An  irredundant  sequence  is  one  in  which  no  two  terms  are  equal.) 


>  show  symbol -tabla-add. 

(DEFINE  SYMBOL-TABLE-AOO 

(LAMBDA  (TABLE  INPUT)  ;MOOIFIES  TABLE. 

(PROG  (INDEX) 

(SETQ  INDEX  (HASH  (CAR  INPUT))) 

(ARRAYSTORE  TABLE  INDEX 

(BUCkET-ADO  (ARRAYFETCH  TABLE  INDEX) 
INPUT))))) 


(DEFINE  HASH 

(LAMBDA  (INPUT) 

...)) 

(DEFINE  BUCKET-AOO 
(LAMBDA  (OLD  INPUT) 

-••)) 

The  user  has  asked  the  system  to  redisplay  code  for  symbol-table-add  based  on  the  additional 
specifications  provided  thus  far.  Notice  that  the  system  still  doesn’t  know  how  the  buckets  are 
implemented,  so  bucket-add  is  still  just  a  placeholder.  However,  the  system  does  now  have  enough 
information  to  make  some  other  implementation  decisions.  For  example,  since  the  hashing  function  does 
not  need  to  be  modified,  it  has  been  implemented  as  a  Lisp  procedure.1  The  only  function  that  needs  to 
be  modified  now  is  the  table  (a  sequence).  The  system  has  also  taken  the  initiative  of  implementing  this 
sequence  as  a  Lisp  vector.  Modifying  a  Lisp  vector  is  achieved  by  arraystore. 

If  desired,  the  user  could  have  been  queried  about  each  of  these  decisions.  However,  it  is  probably 
preferable  to  have  the  system  take  the  initiative  at  this  tow  level  and  make  it  possible  for  the  user  to 


1.  There  is  nothing  in  the  current  plan  library  concerning  what  makes  a  good  hashing  function.  This  is  in  the  domain  of  numerical 
computation  and  theory,  which  is  outside  of  the  focus  of  this  work. 
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retract  decisions  later.2 

>  show  code  for  associative  retrieval  from  a  symbol  table. 

(DEFINE  SYM80L-T ABLE -RETRIEVE 
(LAMBDA  (TABLE  INPUT) 

(BUCKET-RETRIEVE  (ARRAYFETCH  TABLE  (HASH  INPUT)) 

INPUT))) 

(OEFINE  BUCKET-RETRIEVE 
(LAMBDA  (BUCKET  INPUT) 

(PROG  (OUTPUT)  ; SEARCH  LOOP 

(COND  (...  (RETURN  NIL))) 

(SETQ  OUTPUT  ...) 

(COND  ((EQ  (CAR  OUTPUT)  INPUT) 

(RETURN  OUTPUT))) 

(GO  LP))))) 

Associative  retrieval  is  a  standard  specification  known  to  the  system.  Conceptually,  it  has  three 
inputs:  a  set,  a  key  function,  and  a  search  key.  It  also  has  two  cases:  if  there  is  a  member  of  the  set  such 
that  the  key  function  applied  to  it  equals  the  search  key.  then  the  retrieval  succeeds  and  its  output  is  such 
a  member;  otherwise,  it  fails.3 

As  can  be  seen  from  the  code  above,  the  system  also  knows  the  standard  plan  for  implementing 
associative  retrieval  from  a  set  implemented  as  a  keyed  discrimination,  namely:  apply  the  bucket  function 
to  the  search  key  to  obtain  a  bucket;  and  then  perform  associative  retrieval  from  the  bucket  using  the 
same  key  function  and  search  key.  Notice  that  the  respective  sets  (cither  the  whole  table  or  the  bucket) 
and  the  search  key  (input)  are  the  formal  parameters  of  symbol-table-retrieve  and  bucket-retrieve  in 
the  code  above,  while  the  key  function,  car,  is  coded  in  line.  This  coding  docs  not  cause  any  loss  of 
modularity,  since  the  purpose  of  that  particular  use  of  CAR  is  preserved  in  the  plan  representation. 

The  gaps  in  bucket-retrieve  are  due  to  the  fact  that  the  user  has  not  yet  specified  how  the  buckets 
arc  implemented.  However,  the  systems  does  know  that  this  procedure  conceptually  has  two  cases. 
Procedures  in  Lisp  can  have  only  one  return  point  The  system  has  thus  decided  to  use  the  standard 
technique  of  a  flag  to  encode  two  cases  —  a  return  value  of  nil  signals  the  failure  case.  Minor 
programming  techniques,  such  as  the  use  of  flags,  can  also  be  captured  in  the  plan  representation. 

The  following  illustrates  another  kind  of  interaction  between  the  user  and  the  system.  In  addition 
to  being  able  to  read  each  other’s  code,  the  user  and  system  can  also  edit  each  other’s  code.  This 
interaction  also  shows  how  the  plan  library  can  provide  the  user  with  a  sort  of  "macro  expansion”  facility 
for  writing  code  more  easily  and  correctly.  For  example,  the  user  below  invokes  the  standard  plan  for 
generating  successive  elements  of  a  Lisp  list  by  car  and  cdr,  truncated  by  null.  The  code  that  is 
generated  for  this  plan  in  this  context  is  underlined  below. 


2.  A  truth  maintenance  s>stcm  (21.43)  can  Facilitate  this  kind  of  retraction.  The  issues  involved  in  incremental  modification  are  an 
important  part  of  the  programmer's  apprentice  project  in  general,  hut  arc  outside  of  the  focus  of  this  work. 

3.  This  way  of  specifying  associative  retrieval  generalt7.es  well  to  multiple  key  retrieval 


/ 
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>  Insert  code  for  truncated  list  generation  of  bucket  In  bucket-retrieve. 

(DEFINE  BUCKET-RETRIEVE 
(LAMBDA  (BUCKET  INPUT) 

(PROG  (OUTPUT)  ;  LIST  GENERATION  AND  SEARCH  LJo« 

LP  (CONO  1 1  NULL  BUCKET  HRETURH  NIL))) 

(SETQ  OUTPUT  (CAR  BUCKET1 1 
(COND  ((EQ  (CAR  OUTPUT)  INPUT) 

(RETURN  OUTPUT))) 

(SETQ  BUCKET  ( CDR  BUCKET  11 
(GO  LP))))) 


The  important  difference  between  what  takes  place  here  and  a  conventional  macro  facility  is  that 
here  the  insertion  of  new  material  takes  place  in  the  plan  calculus,  where  the  benefits  of  additivity  hold. 
Only  afterwards  is  code  regenerated  from  the  augmented  plan. 

Notice  that  the  user  here  has  indirectly  told  the  system  that  the  buckets  of  the  symbol  table  are 
implemented  as  lists.  This  gives  the  system  enough  information  to  complete  the  implementation  of 
bucket-retrieve  by  identifying  the  exit  test  of  the  list  generation  with  the  failure  case  of  the  associative 
retrieval,  (return  nil),  and  by  setting  output  to  the  successively  generated  list  elements. 


>  show  symbol -tabla-add. 

(DEFINE  SYNBOL-TABLE-ADO 

(LAMBOA  (TABLE  INPUT)  ;MODIFIES  TABLE. 

(PROG  (INDEX) 

(SETQ  INDEX  (HASH  (CAR  INPUT))) 

(ARRAYSTORE  TABLE  INDEX 

ICONS  (ARRAYFETCH  TABLE  INDEX) 
INPUT))))) 


Given  that  buckets  are  implemented  as  lists,  the  system  assumes  the  most  straightforward 
implementation  for  bucket-add  which  is  simply  cons,  as  shown  above. 


>  describe  the  Implemantatlon  of  a  symbol  tabla. 

A  SYMBOL  TABLE  IS  IMPLEMENTED  AS  A  DISCRIMINATION  FUNCTION. 

THE  BUCKETS  OF  THE  DISCRIMINATION  FUNCTION  ARE  IMPLEMENTED  AS  LISTS. 

THE  DISCRIMINATION  FUNCTION  IS  IMPLEMENTED  AS  A  KEYED  DISCRIMINATION. 

THE  KEY  FUNCTION  OF  THE  KEYED  DISCRIMINATION  IS  CAR. 

THE  BUCKET  FUNCTION  OF  THE  KEYED  DISCRIMINATION  IS  IMPLEMENTED  AS  A  HASHING. 

THE  HASH  FUNCTION  OF  THE  HASHING  IS  IMPLEMENTED  AS  A  LISP  PROCEDURE. 

THE  TABLE  OF  THE  HASHING  IS  IMPLEMENTED  AS  A  LISP  VECTOR. 


Above  we  see  how  the  programmer’s  apprentice  can  provide  an  interactive  documentation  facility. 
This  can  be  particularly  useful  if  more  than  one  programmer  is  working  on  a  program,  or  if  a  program 
needs  to  be  modified  a  long  time  after  it  was  written. 
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>  show  code  for  associative  deletion  from  a  symbol  table  by  side  effect. 

(DEFINE  SYMBOL-TABLE -DELETE 

(LAMBDA  (TABLE  INPUT)  ;MODIFIES  TABLE. 

(PROG  (INDEX) 

(SETQ  INOEX  (HASH  INPUT)) 

(ARRAYSTORE  TABLE  INDEX 

(BUCKET-DELETE  (ARRAYFETCH  TABLE  INDEX)))))) 

(DEFINE  BUCKET-DELETE 
(LAMBDA  (BUCKET  INPUT) 

(COND  ((NULL  BUCKET)  NIL) 

( { EO  (CAAR  BUCKET)  INPUT) 

(BUCKET-DELETE  (CDR  BUCKET)  INPUT)) 

(T  (CONS  (CAR  BUCKET) 

(BUCKET-DELETE  (CDR  BUCKET)  INPUT)))))) 


Associative  deletion  is  also  a  standard  specification  known  to  the  system.  Like  associative  retrieval, 
it  has  three  inputs:  a  set,  a  key  function,  and  a  key.  Its  output  is  the  input  set  minus  those  members  for 
which  the  key  function  applied  to  them  equals  the  input  key.  The  implementation  of  associative  deletion 
from  a  set  implemented  as  a  discrimination  function  is  a  similar  three  step  plan  to  the  set  addition  plan 
introduced  earlier,  namely:  apply  the  discrimination  function  to  get  a  bucket,  perform  the  same 
associative  deletion  on  the  bucket  to  get  a  new  bucket,  and  then  modify  the  discrimination  function  to 
incorporate  the  new  bucket.  The  system  has  generated  code  for  this  plan  as  shown  above. 

Notice  that  associative  deletion  from  the  bucket  list  is  implemented  by  the  system  in  the 
straightforward  manner  which  copies  the  list.  In  the  next  frame,  we  will  see  that  the  user  has  something 
more  clever  in  mind,  and  therefore  intervenes  to  provide  his  own  more  efficient  code  for  deleting  from 
the  bucket  by  side  effect 


>  adit  bucket-delete 

(define  buckat-dalata 

(lambda  (bucket  Input)  ;mod1f1es  bucket, 

(prog  (p  q) 

(setq  p  bucket) 
lp  (cond  ((eq  (caar  p)  Input) 

(rplacd  q  p)  ; splice  out. 

(return  bucket))) 

(setq  q  p) 

(setq  p  (edr  p)) 

(90  ip)))) 

WARNING!  THE  LOOP  IN  BUCKET-OELETE  IS  ALMOST  A 
TRAILING  GENERATION  ANO  SEARCH, 

CURRENT:  P 
'  PREVIOUS :  0 

EXIT:  (COND  ((EQ  (CAAR  P)  ...))) 

ACTION:  (CDR  P) 

EXCEPT  THAT  THE  OUTPUT  OF  THE  ACTION  IS  JJfil  EQUAL  TO  THE 
INPUT  OF  THE  EXIT  TEST. 


Here  we  see  an  example  of  inspection  methods  used  •  verification.  The  user  has  attempted  to 
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code  a  generation  and  search  loop  with  a  trailing  value  and  has  not  gotten  it  quite  right.1  The  plan  in  the 
library  for  trailing  generation  and  search  has  the  roles  for  the  current  value,  the  previous  value,  the  exit 
test,  and  the  generating  action  on  each  iteration,  with  roughly  the  following  constraints  between  them: 

(i)  The  output  of  the  action  is  equal  to  the  input  of  the  action  on  the  next  iteration. 

(ii)  The  output  of  the  action  is  equal  to  the  input  of  the  exit  test. 

(iii)  The  current  value  is  equal  to  the  input  of  the  exit  test. 

(iv)  The  current  value  is  equal  to  the  previous  value  on  the  next  iteration. 

(v)  The  current  value  and  previous  value  are  outputs  of  the  loop. 

In  a  near-miss  recognition,  most  but  not  all  of  the  constraints  of  a  plan  are  satisfied.  In  this 
example,  constraint  (ii)  is  not  satisfied  as  indicated  by  the  system  in  the  warning  message  above.2  The 
details  of  how  this  recognition  takes  place  are  explained  in  Chapter  Seven. 

Verification  by  inspection  yields  a  much  more  meaningful  diagnostic  than  would  be  given  by  other 
methods  of  detecting  this  error.-  For  example,  running  the  code  above  with  certain  inputs  would  result  in 
the  Lisp  interpreter  halting  at  the  rplacd  with  an  error  message  such  as  the  following. 

;  MIL  BAO  ARC  -  RPLACD 

In  general,  correcting  errors  is  more  difficult  than  detecting  them.  For  example,  it  is  hard  for  the 
system  to  know  whether  a  near-miss  is  actually  an  error  or  just  a  new  variation  on  a  plan  it  doesn't  know 
about.  The  programmer’s  apprentice  will  thus  in  general  rely  on  the  user  to  correct  errors.  The  user's 
response  to  the  warning  message  above  is  shown  underlined  below. 

>  adit  bockat-dalata 

(daflna  buckat-dalata 

(lambda  (buckat  Input)  ;«od1f1as  buckat. 

(prog  (p  q) 

(Kta  a  buskit) 

Ip  tseto  p  (edr  all 

(cond  ( ( eq  (caar  p)  Input) 

(rplacd  q  p)  ; splice  out. 

(return  bucket))) 

(setq  q  p) 

(9«»  IP)))) 

WARNING t  THE  C00E  (RPLACD  Q  P)  IS  NOT  RECOGNIZED  AS  SPLICEOUT. 

SUGGEST  (RPLACD  Q  (COR  P))  7  yes 

Unfortunately,  there  is  yet  another  error  in  the  user’s  code.  The  user  has  asserted  in  a  comment 
above  that  the  line  with  rplacd  implements  splicing  an  element  out  of  the  list  However,  the  system  finds 
that  this  code  docs  not  match  its  library  plan  for  splicing  out  In  this  case,  since  the  user  has  stated  his 
intention  in'  a  comment,  the  system  can  go  as  far  as  offering  a  correction,  which  the  user  accepts. 


1.  Whether  or  not  the  user  should  have  known  that  this  particular  plan  was  in  the  library  is  irrelevant  The  point  here  is  to 
illustrate  the  idea  of  a  program  understanding  system  that  "looks  over  the  shoulder"  of  the  user. 

2.  This  docs  not,  however,  mean  the  user's  code  won't  work;  only  that  the  system  does  not  have  a  theory  by  which  it  can 
understand  what  the  code  does. 
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Notice  that  at  different  points  in  this  scenario,  Lisp  lists  have  been  viewed  both  recursively  and  as 
directed  graphs.  The  first  version  of  bucket-delete  was  a  standard  recursion  on  the  tail  of  the  list;  while 
the  version  above  is  in  the  domain  of  graph  manipulations  involving  successor  nodes  and  modifying  arcs 
between  them. 

Now  that  bucket -delete  has  been  re-implemented  using  side  effects,  a  more  efficient 
implementation  of  symbol-table-delete  is  possible,  in  which  the  arraystore  is  necessary  only  if  the  first 
element  of  the  bucket  is  deleted 

>  shoo  symbol -table-d»lett. 

(DEFINE  SYMBOL-TABLE-DELETE 

( LAM80A  (TABLE  INPUT)  ;MOOIFIES  TA8LE . 

(PROG  (INOEX  BUCKET) 

(SETQ  INOEX  (HASH  INPUT)) 

(SETQ  BUCKET  (ARRAYFETCH  TABLE  INDEX)) 

(COND  ((EQ  (CAAR  BUCKET)  INPUT) 

(ARRAYSTORE  TABLE  INDEX  (CDR  BUCKET))) 

(T  (BUCKET-DELETE  BUCKET)))))) 

To  come  to  this  implementation,  the  system  has  done  some  analysis  of  side  effects  by  inspection. 
Specifically,  there  arc  plans  and  an  overlay  in  the  library  which  say  that  one  way  to  modify  a  function 
(change  the  associations  between  domain  and  range  elements  by  adding  a  new  range  element)  is  to 
modify  an  old  range  clement.  Applied  to  this  program,  this  overlay  allows  the  system  to  view  the  deletion 
of  an  element  from  the  bucket  by  side  effect  as  the  implementation  of  the  modification  of  the 
discrimination  function. 

Analysis  by  inspection  is  also  in  operation  here.  By  recognizing  the  user's  bucket-delete  code  as  a 
trailing  generation  and  search  plan,  the  system  derives  some  important  additional  properties  of  this 
procedure.  In  particular,  it  knows  that  this  procedure  only  searches  internal  nodes  of  the  bucket  list,  and 
that  it  only  finds  the  first  node  which  has  the  given  key.  With  regard  to  the  first  property,  there  is  a  plan 
in  the  library  which  combines  an  internal  deletion  with  a  conditional  test  on  the  first  node  to  achieve  a 
complete  deletion.  The  system  has  used  this  plan  to  arrive  at  the  code  above.  The  second  property  is 
propagated  up  to  the  specifications  of  symbol-table-delete,  as  shown  below. 

>  describe  preconditions  of  symboT-table-delete. 

THERE  EXISTS  A  UNIQUE  ”X"  SUCH  THAT  X  BELONGS  TO  THE  OLD  SYMBOL  TABLE, 

AND  THE  CRITERION  APPLIED  TO  X  IS  TRUE. 

>  describe  preconditions  of  symbol-table- Insert. 

THE  INPUT  DOES  NOT  BELONG  TO  THE  OLD  SYMBOL  TABLE. 

Thus  analysis  by  inspection  has  revealed  some  important  additional  restrictions  which  the  user 
either  was  not  clearly  aware  of,  or  in  any  case,  did  not  explicitly  state.  The  propagation  of  restrictions 
from  the  specifications  of  bucket-delete  to  symbol-table-delete  and  symbol-table-add  could  be 
achieved  by.  the  use  of  general  reasoning  mechanisms.  However,  these  arc  such  common  specializations 
of  the  most  general  addition  and  deletion  specifications  that  they  arc  appropriately  prc-compiicd  in  the 
library. 
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CHAPTER  THREE 
OVERVIEW  OF  THE  PLAN  LIBRARY 


3.1  Introduction 

This  chapter  gives  an  overview  of  the  plan  library  with  an  emphasis  on  taxonomy;  English 
descriptions  and  example  programs  are  used  to  give  a  feeling  for  the  extent  and  overall  organization  of 
the  knowledge  in  the  library.  Formal  definitions  for  all  library  entries  can  be  found  in  the  appendix  (see 
index  for  page  numbers)  written  in  a  notation  which  is  explained  in  Chapter  Eight.  Chapters  Five,  Six 
and  Seven  describe  the  use  of  the  library  in  specific  scenarios  of  analysis,  synthesis  and  verification  by 
inspection. 

Methodology 

My  basic  approach  in  developing  a  taxonomy  of  standard  programming  forms  has  been  to  start 
with  the  technical  vocabulary  commonly  used  and  understood  by  experienced  programmers,  and  then  to 
apply  my  own  intuitions  to  make  appropriate  generalizations  and  distinctions.  I  thus  take  the  position 
that  if  programmers  have  evolved  a  name  for  something,  it  is  probably  an  important  concept  This 
means,  for  example,  that  there  arc  plans  in  the  library  which  capture  the  meaning  of  terms  like  "trailing 
pointer",  "search  loop"  and  "splice  out”. 

Another  method  I  have  used  to  discover  important  programming  concepts  is  to  look  for 
abstractions  which  unify  the  explanations  of  how  many  different  programs  work.  For  example,  the 
concept  of  a  directed  graph  makes  it  possible  to  express  a  number  of  standard  algorithms  independent  of 
how  the  nodes  and  edges  are  represented  in  a  particular  program.  This  line  of  argument  has  also  lead  to 
including  in  the  library  a  number  of  other  familiar  mathematical  objects,  such  as  functions,  relations, 
sequences  and  sets. 

Let  me  emphasize  that  the  taxonomy  represented  in  the  current  library  is  only  intended  to  be  a 
beginning.  The  exact  contents  of  the  current  library  has  been  determined  primarily  by  the  requirements 
of  giving  a  complete  account  of  one.  medium-sized  example  program,  capturing  all  the  important 
generalizations.  The  example  program  that  was  chosen  for  this  is  the  symbol  table  program  introduced  in 
the  scenario  of  Chapter  Two.  This  particular  program  was  chosen  because  it  contains  many  different 
forms  which  arc  representative  of  common  manipulations  on  symbolic  data.  1  felt  that  a  library  which 
was  adequate  for  this  example  would  be  a  good  start  towards  exploring  the  extent  of  this  domain.  I  also 
felt  that  concentrating  on  one  example  in  depth  would  lead  to  a  better  understanding  of  the  relationship 
between  different  levels  of  abstraction,  rather  than  touching  on  only  the  major  points  of  many  different 
programs. 
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Both  of  these  intuitions  have  turned  out  to  be  good.  Capturing  all  the  important  generalizations  in 
this  one  program  has  touched  upon  a  wide  range  of  basic  programming  techniques.  A  complete  account 
of  the  symbol  table  program  has  required  filling  the  library  with  plans  starting  at  a  very  abstract  level, 
such  as  the  idea  of  implementing  a  set  as  a  discrimination  function,  down  to  the  level  of  minor 
programming  techniques,  such  as  the  use  of  flags  to  encode  control  information  in  binary  valued  data. 

The  small  fraction  of  plans  in  the  current  library  which  are  not  directly  motivated  by  the  symbol 
table  example  fall  into  two  categories.  Some  of  these  are  obviously  important  basic  plans  which  don’t 
happen  to  be  used  in  the  example,  such  as  counting  and  accumulation  loops.  Other  plans  arc  included  to 
fill  obvious  gaps  in  the  taxonomic  structure  of  the  library,  such  as  the  plan  for  splicing  into  a  list  (whereas 
only  splicing  out  appears  in  the  symbol  table  program). 

Finally,  while  1  do  argue  for  the  major  outlines  and  organization  of  the  current  library,  I  do  not 
expect  that  any  reader  will  agree  on  every  last  detail.  Many  common  manipulations  on  symbolic  data  arc 
missing  at  present  The  current  library  also  needs  to  be  expanded  in  many  different  directions,  such  as  to 
include  more  general  graph  algorithms,  matrix  manipulations,  and  so  on.  However,  it  will  hopefully  be 
clear  after  reading  this  chapter  where  many  of  these  extensions  fit  into  the  existing  structure. 

Implementation  Relationships 

A  vocabulary  of  standard  forms  is  not  the  only  kind  of  knowledge  involved  in  programming.  A 
programmer  also  knows  many  ways  of  implementing  one  form  in  terms  of  others.  The  idea  of 
implementing  a  set  as  a  hash  table,  or  of  removing  an  entry  from  a  list  by  splicing  it  out,  are  examples  of 
implementation  relationships  (represented  in  the  library  by  overlays).  In  building  the  library,  the  choice 
of  programming  vocabulary  was  often  influenced  by  the  implementation  relationships.  The  motivation 
for  making  a  vocabulary  distinction  was  often  to  separate  two  cases  which  allow  different 
implementations.  For  example,  finite  and  infinite  sets  are  distinguished  in  the  library  because 
membership  tests  in  finite  sets  may  be  implemented  by  a  loop  which  enumerates  the  elements,  which  is 
not  a  valid  implementation  for  infinite  sets.  (The  set  of  natural  numbers  is  an  example  of  an  infinite  set 
which  is  part  of  basic  programming.) 

An  important  kind  of  knowledge  which  is  not  yet  explicitly  represented  in  the  library  is  the  relative 
cost  of  various  computations.  However,  I  believe  that  in  fact  much  of  an  expert  programmer’s  knowledge 
about  the  relative  cost  of  computations  is  embedded  in  his  vocabulary.  In  other  words,  given  that  cost 
considerations  are  the  primary  motivation  behind  many  standard  programming  ideas,  the  study  of  these 
ideas  is  a  logical  starting  place  for  developing  an  understanding  of  computational  cost.  For  example,  the 
idea  of  a  hash  table  is  motivated  by  the  desire  to  speed  up  various  kinds  of  retrieval  operations.  This 
increase  in  speed  is  due  to  the  fact  that  any  single  bucket  in  the  table  is  smaller  than  the  union  of  all  the 
buckets.  Future  research  will  include  studying  the  library  further  from  this  viewpoint  in  order  to  make 
this  kind  of  knowledge  more  explicit 
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Overall  Organization 

The  current  library  contains  approximately  fifty  input-output  and  test  specifications,  thirty  data 
plans,  and  thirty  temporal  plans.  These  plans  and  specifications  arc  organized  in  two  ways:  in  a 
taxonomic  hierarchy  and  by  an  interlocking  network  of  approximately  fifty  overlays.  There  are  two 
taxonomic  relationships  used  in  the  library:  specialization  and  extension.  Note  that  a  plan  may  be  a 
specialization  or  extension  of  more  than  one  other  plan,  so  that  the  taxonomic  hierarchy  may  be  tangled. 

A  plan  or  specification  is  a  specialization  of  another  plan  or  specification  if  it  has  the  same  roles,  but 
additional  constraints.  This  means  that  the  computations  or  data  structures  specified  by  the  specialized 
plan  arc  a  subset  of  those  specified  by  the  more  general  plan. 

A  common  motivation  for  introducing  a  specialization  of  a  plan  is  because  the  properties  of  the 
specialization  are  exploited  in  some  particular  implementation.  For  example,  consider  the  data  plan. 
Segment,  introduced  in  Chapter  One.  This  data  plan  has  three  roles:  a  base  sequence,  an  upper  index, 
and  a  lower  index.  One  way  of  implementing  a  mutable  stack  is  to  use  an  instance  of  Segment  in  which 
only  the  lower  index  is  varied  —  the  upper  index  is  always  equal  to  the  length  of  the  base  sequence.  This 
data  plan  is  called  Upper-segment;  it  is  a  specialization  of  Segment.  Upper-segment  has  the  same  role 
names  as  Segment.  Its  constraints  arc  the  three  constraints  of  Segment,  i.e. 

(i)  The  upper  number  is  less  than  or  equal  to  the  length  of  the  base  sequence. 

(ii)  The  lower  number  is  less  than  or  equal  to  the  length  of  the  base  sequence. 

(iii)  The  lower  number  is  less  than  or  equal  to  the  upper  number. 

plus  the  following  specializing  constraint 

(iv)  The  upper  number  is  equal  to  the  length  of  the  base  sequence. 

The  basic  idea  of  extension  is  to  add  an  additional  role  to  a  plan  or  specification.  The  extended  plan 
inherits  all  the  constraints  of  the  old  plan. 

A  common  kind  of  extension  is  to  add  an  additional  output  to  an  input-output  specification.  For 
example.  Thread-find  is  the  standard  input-output  specification  for  finding  a  node  satisfying  a  given 
criterion  in  a  linear  directed  graph  (thread).  It  has  two  input  roles,  named  Input  and  Criterion,  and  one 

output  role,  named  Output.  The  Output  is  a  node  of  the  Input  thread  which  satisfies  the  Criterion 

predicate.  When  Thread-find  operations  are  used  in  conjunction  with  other  plans,  such  as  splicing,  it  is 
convenient  to  have  as  output  not  only  the  node  found,  but  also  the  previous  node  in  the  thread.  This 
extension  to  Thread-find  is  called  lnternal-tlircad-find.  lntcmal-thread-find  has  the  same  input  roles  as 
Thread-find,  but  two  output  roles.  Output  and  Previous,  with  the  additional  constraint  that  Previous  is  the 
predecessor  node  of  Output  in  the  Input  thread. 

Object  Types 

Part  of  the  hierarchy  of  object  types  is  shown  in  Fig.  3-1.  All  the  names  in  this  figure  arc  the  names 
either  of  primitive  object  types  or  data  plans.  Similar  figures  later  in  this  chapter  will  also  include  the 
names  of  input-output  and  test  specifications,  and  temporal  plans.  Solid  vertical  lines  between  names  in 
these  figures  denote  specialization  or  extension  relationships,  with  the  specialized  or  extended  plan  always 
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below.  Arrows  in  these  figures  represent  overlays  between  plans.  Most  overlays  are  many-to-one 
mappings  from  instances  of  one  plan  to  another.  The  arrow  for  such  overlays  points  from  the  domain  to 
the  range.  Overlays  that  are  one-to-one  are  indicated  by  double-headed  arrows.  Dotted  lines  indicate 
"use”  relations.  For  example,  labelled-digraph  is  defined  using  the  definition  of  Digraph. 

Referring  to  Fig.  3-1,  note  that  the  root  node  in  the  data  object  hierarchy  is  called  Object.  Below 
Object  are  the  primitive  types  in  the  current  library:  Integer,  Function,  Binfunction  (functions  of  two 
arguments),  and  Set.  By  "primitive"  1  mean  here  that  systems  which  use  the  plan  library  arc  expected  to 
have  specific  procedures  for  reasoning  about  these  objects,  and  that  this  knowledge  is  not  explicitly 
represented  in  the  library  itself. 

The  notion  of  Integer  used  here  is  a  standard  extension  of  the  finite  integers  with  a  maximum 
element,  infinity,  and  a  minimum  element,  minus-infinity.  Integer  has  specializations  Natural  and 
Cardinal.  Instances  of  Natural  arc  all  the  integers  greater  than  or  equal  to  one,  not  including  infinity. 
Instances  of  Cardinal  are  all  the  integers  greater  than  or  equal  to  zero,  including  infinity. 

Subsequent  main  sections  of  this  chapter  give  overviews  of  parts  of  the  library  under  the  other  main 
nodes  in  this  hierarchy.  There  is  a  section  about  plans  involving  functions,  one  about  plans  involving  sets, 
one  about  directed  graphs,  and  one  about  recursive  structures.  However,  these  sections  will  not  be  able  to 
discuss  every  plan  in  the  library,  since  that  would  make  the  figures  an  unreadable  clutter.  For  example, 
some  plans  involving  minor  programming  techniques,  such  as  the  use  of  flags  and  various  ways  of 
implementing  predicate  tests  are  discussed  as  they  arise  in  the  later  chapters  (and  their  definitions  can  be 
found  in  the  appendix.) 

Notice  the  overlays  in  the  middle  of  Fig.  3-1  between  Sequence,  List,  Thread,  and  Labelled-thread. 
These  overlays  will  be  explained  in  more  detail  in  subsequent  sections.  For  now  it  is  important  just  to 
point  out  this  example  of  how  multiple  of  points  of  view  are  catalogued  in  the  library.  Each  of  these  data 
plans  (Sequence  is  a  specialization  of  the  primitive  object  type  Function)  captures  an  alternative  point  of 
view  on  what  could  be  called  linear  structures. 

3.2  Functions 

Fig.  3-2  shows  the  part  of  the  plan  library  which  involves  functions.  At  the  top  left  are  three  basic 
input-output  specifications  which  have  functions  as  inputs  or  outputs.  ©Function  is  the  specification  for 
applying  a  function  to  an  argument  to  get  a  value.1 

Another  common  operation  performed  on  functions  is  to  change  the  value  associated  with  a  given 
argument.  The  input-output  specification  for  this  operation  is  called  Newarg.  Ncwarg  has  three  inputs: 
the  old  function,  an  argument,  and  the  new  value.  The  output  is  a  new  function  such  that  the  given 
argument  maps  to  the  new  value  and  the  values  of  all  other  arguments  remain  unchanged. 

A  less  commonly  used  specification  is  Nenvalue.  Newvalue  also  has  three  inputs:  the  old  function, 
an  old  value,  and  a  new  value.  The  output  is  a  new  function  such  that  all  the  arguments  that  used  to  map 


1.  Hie  character  "<®"  is  intended  to  be  read  as  "apply". 
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Figure  3-2.  Plans  Involving  Functions. 
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to  the  old  value  now  map  to  the  new  value  and  the  values  of  other  arguments  remain  unchanged. 
Ncwvalue  will  be  used  as  part  of  the  analysis  of  operations  on  hash  tables. 

Notice  that  these  specifications  make  no  commitment  as  to  whether  the  old  function  is  copied  or 
modified  to  get  the  new  function.  The  copying  and  side  effect  versions  will  be  treated  as  specializations. 
The  input-output  specification,  Old+new,  of  which  Newarg  and  Newvalue  are  extensions,  is  a  very 
general  form  which  makes  it  possible  to  state  this  idea  in  general.  It  is  advantageous  to  work  with  these 
more  abstract  specifications  as  much  as  possible,  since  they  unify  the  logical  structure  of  a  larger  number 
of  programs.  These  same  remarks  apply  to  all  other  input-output  specifications  in  this  chapter  which  are 
shown  as  extensions  of  Old+new.  Plans  involving  side  effects  are  discussed  further  in  Chapter  Eight 

At  the  middle  left  of  Fig.  3-2  are  some  plans  having  to  do  with  implementing  a  function  as  the 
composition  of  two  functions,  i.e.  by  the  data  plan  Composed-functions. 

Composcd-@functions  is  a  temporal  plan  for  implementing  (©Function  for  a  function  implemented 
as  Composed-functions,  i.c.  apply  the  second  function  of  the  composition  to  the  output  of  applying  the 
first  function  to  the  given  argument 

The  plan  Newvaluc-coinposed  and  the  overlay  between  it  and  Newvalue  express  the  fact  that  a 
Newvalue  operation  on  a  function  implemented  as  Composed-functions  can  be  implemented  by  a 
Newvalue  operation  on  the  second  function  of  the  composition  alone.  This  plan  arises  in  the  analysis  of 
the  symbol  table  example,  where  the  hash  table  is  viewed  as  the  composition  of  two  functions:  a 
numerical  hash  function  which  doesn’t  change,  and  an  array  that  is  modified  to  insert  new  entries. 

Notice  that  the  data  plan  Hashing  is  a  specialization  of  Composed-Functions.  As  we  have  seen  in 
the  scenario,  the  first  function  in  this  case  is  referred  to  as  the  hash  function,  and  the  second  (a  sequence) 
is  referred  to  as  the  table.  A  discrimination  function  can  be  implemented  as  a  hash  table,  in  which  case 
the  table  is  a  sequence  of  sets,  called  the  buckets.  The  utility  of  this  implementation  is  that  changes  (e.g. 
Newvalue  operations)  to  a  discrimination  implemented  this  way  may  be  achieved  by  changing  only  the 
table,  as  specified  by  the  Newvalue-composed  plan  discussed  above.  Discrimination  functions  will  be 
discussed  further  in  the  next  section  on  sets. 

Sequences 

Sequences  are  viewed  formally  as  functions  on  the  natural  numbers  which  are  defined  on  some 
initial  interval  (up  to  the  length  of  the  sequence)  and  undefined  elsewhere.  A  common  specialization  is 
Irrcdundant-scquence,  i.e.  sequences  in  which  no  two  terms  are  equal. 

A  number  of  common  operations  on  linear  structures  arc  most  naturally  specified  in  terms  of 
sequences.  Fig.  3-2  shows  several  such  input-output  specifications.  The  first  two  specifications.  Term 
and  Newtcrm,  arc  simply  specializations  of  ^’Function  and  Newarg  to  the  case  when  the  functions 
involved  arc  sequences. 

The  next  two  specifications  have  to  do  with  truncating  sequences  according  to  some  criterion  (a 
predicate).  In  both  cases  a  precondition  is  that  there  exist  some  term  of  the  input  sequence  which  satisfies 
the  criterion.  The  output  sequence  in  both  cases  is  a  finite  initial  subsequence  of  the  input  sequence.  In 
the  case  of  Truneutc-inclusivc,  all  but  the  last  term  of  the  output  sequence  fail  the  criterion;  the  last  term 
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passes.  In  the  case  of  Truncate,  all  terms  of  the  output  sequence  fail  the  criterion  and  the  length  of  the 
output  sequence  is  one  less  than  the  index  of  the  first  term  in  the  input  sequence  that  passes  the  criterion. 

A  closely  related  input-output  specification  is  Earliest.  Again  the  inputs  are  a  sequence  and  a 
criterion,  and  a  precondition  is  that  there  exist  some  term  of  the  input  sequence  which  satisfies  the 
criterion.  The  output  is  the  earliest  term  of  the  sequence  which  passes  the  criterion,  i.c.  all  terms  with 
indices  lower  than  the  index  of  the  output  fail  the  criterion. 

The  last  input-output  specification  on  sequences  in  Fig.  3-2  is  Map.  Its  input  and  output  are 
sequences  of  the  same  length.  An  additional  input  (Op)  is  a  function  such  that  each  term  of  the  output  is 
the  result  of  applying  that  function  to  the  corresponding  term  of  the  input 

Aggregations 

This  section  introduces  some  simple  algebraic  structure  which  captures  the  similarity  between 
programs  which  compute  sums,  products,  set  unions  and  intersections,  maximums  and  minimums.  The 
input-output  specification  which  is  the  generalization  of  all  these  operations  is  called  Aggregate. 
Aggregate  takes  as  input  a  (non-empty,  finite)  set  of  objects  and  a  function  of  two  arguments  which  is 
commutative,  associative  and  has  identity  elements.  Such  a  function  is  called  an  Aggrcgative-binfunction. 
(If  the  function  also  has  an  inverse,  then  it  is  an  Abelian  group.)  The  output  of  Aggregate  is  the  result  of 
composing  the  application  of  the  aggregative  function  to  the  members  of  the  input  set.  The  algebraic 
properties  of  aggregative  functions  guarantee  that  the  order  of  this  composition  doesn’t  matter.1 

Fig.  3-2  also  names  six  common  specializations  of  Aggregate  for  particular  aggregative  functions: 
Sum  (Plus),  Product  (Times),  Aggregate-union  (Union),  Aggregate-intersection  (Intersection),  Max 
(Greater),  and  Min  (Lesser). 

Relations 

Relations  are  treated  formally  as  boolean  valued  functions.  A  Predicate  is  a  boolean  valued 
function  of  one  argument;  a  Binrel  is  a  boolean  valued  function  of  two  arguments.  Correspondingly, 
@Prcdicate  is  the  specialization  of  ©Function  to  predicates,  and  @Binrcl  is  the  specialization  of 
@Binfiinction  to  binary  relations. 

Note  in  Fig.  3-2  the  overlay  between  Partial-order  and  Aggregative-binfunction.  Ihis  overlay 
allows  the  following  code 

(CONO  ((>  N  MAX)(SETQ  MAX  N))) 

to  be  analyzed  as  an  application  of  the  Lesser  function  ,  which  then  allows  a  loop  with  this  code  in  the 


1.  Which  is  why  the  input  is  a  set  rather  than  a  list  or  sequence.  Also  there  is  some  subtlety  being  suppressed  here  concerning 
whether  the  input  should  be  a  set  or  a  multiset  In  the  case  of  union,  intersection,  maximum  and  minimum,  the  occurrence  of 
duplicates  doesn't  matter,  and  therefore  the  set  abstraction  is  definitely  appropriate.  Sum  and  product  however,  do  not  have  this 
property.  Nevertheless,  I  argue  that,  conceptually,  the  input  to  a  summation  operation  is  a  of  objects  in  the  sense  that  even 
though  viewed  as  integers  they  may  have  the  same  behavior,  they  represent  conceptually  distinct  quantities  and  are  therefore  not 
identical.  Sec  Chapter  Eight  for  more  on  the  notion  of  behavior  versus  identity. 
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body  to  be  analyzed  as  the  implementation  of  the  Min  operation  (and  similarly,  when  the  test  is  "<",  the 
implementation  of  Max). 

3.3  Sets 

Fig.  3-3  shows  part  of  the  plan  library  which  involves  sets.  At  the  left  of  the  figure  we  have  first 
some  common  input-output  and  test  specifications  with  sets.  Member?  tests  whether  a  given  object  is  a 
member  of  a  given  set.  Any  is  a  more  complicated  test:  given  a  set  and  a  predicate  as  inputs,  it  succeeds  if 
there  exists  a  member  of  the  set  which  satisfies  the  predicate,  and  returns  such  a  member  as  its  output; 
otherwise  it  fails.  Set- find  is  a  related  input-output  specification:  it  has  the  precondition  that  there  that 
there  exists  a  member  of  the  input  set  which  satisfies  the  input  predicate,  and  simply  returns  such  a 
member  as  its  output 

The  next  two  input-output  specifications  each  have  a  set  as  input  and  a  set  as  output  Each  is  a 
specification  used  to  analyze  programs  like  (mapcar  ’sqrt  l),  where  the  input  list  t,  is  viewed  as  a  set 
and  sort  is  a  function  applied  to  each  element  of  the  set  to  get  an  output  set  Restrict  takes  as  input  a  set 
and  a  predicate  and  returns  the  subset  which  satisfies  the  predicate.  As  in  the  case  of  functions,  no 
commitment  is  made  in  these  specifications  to  whether  the  old  set  is  copied  or  modified  to  get  the  new 
set 

Finally,  Set-add  and  Set-remove  specify  addition  of  a  given  object  to  a  set  and  removal  of  a  given 
object  from  a  set.  The  very  abstract  specification  Old+input+new-sct,  of  which  both  Set-add  and  Set- 
remove  are  specializations,  captures  what  the  implementations  of  these  specifications  have  in  common. 

The  implementation  of  sets  is  a  very  rich  area  of  programming  technique  [62].  It  is  not  the  goal 
here  to  be  exhaustive  of  all  of  the  possibilities,  but  rather  to  show  by  example  how  to  go  about 
formalizing  such  implementations  using  the  plan  calculus.  In  addition  to  the  standard  simple 
implementations  of  sets  as  sequences  and  lists,  this  section  presents  two  examples  of  non-trivial  set 
implementations  which  are  involved  in  understanding  the  the  symbol  table  program. 

The  overlay  for  viewing  a  list  as  the  implementation  of  a  set  is  recursively  defined:  an  object  is  a 
member  of  the  implemented  set  iff  it  is  the  head  of  the  list  or  it  is  a  member  of  the  set  implemented  by 
the  tail  of  the  list.  The  empty  set  is  usually  implemented  by  Nil.  There  are  also  overlays  in  the  library  for 
viewing  Push  and  Pop  operations  as  Set-add  and  Set-remove  operations.  TT»e  implementation  of  other  set 
operations  is  more  naturally  expressed  taking  the  point  of  view  of  the  list  as  a  directed  graph,  which  will 
be  discussed  in  the  next  section. 

Discrimination 

One  .basic  idea  underlying  many  set  implementations  is  the  use  of  a  function  (called  a 
Discrimination),  whose  range  is  a  set  of  sets  (called  buckets).  Such  a  function  can  be  viewed  as 
implementing  a  set  -herein  a  given  object  is  a  member  iff  it  is  a  member  of  the  bucket  obtained  by 
applying  the  discrimination  function  to  that  object.  This  is  the  basic  "divide  and  conquer"  strategy 
underlying  both  hash  tables  and  discrimination  nets. 
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Figure  3*3.  Plans  Involving  Sets. 
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Testing  for  membership  in  a  set  implemented  as  a  discrimination  is  implemented  by  the  two  step 
plan  Discriminate+member?.  The  first  step  is  to  apply  the  discrimination  function  to  the  given  object  to 
determine  which  bucket  to  look  in.  The  second  step  is  an  instance  of  Member?,  with  the  input  set  being 
the  bucket  fetched  by  the  first  step.  Since  any  single  bucket  in  a  discrimination  is  smaller  than  the  overall 
implemented  set,  (except  in  the  case  of  a  degenerate  discrimination  function  which  maps  all  objects  to  a 
single  bucket),  this  implementation  leads  to  a  increase  in  speed  at  the  cost  in  space  for  encoding  the 
discrimination  function. 

Both  Set-add  and  Set-remove  for  input  and  output  sets  implemented  as  discriminations  are 
implemented  by  specializations  of  the  same  three  step  plan:  first,  apply  the  discrimination  function  to  the 
input  object  to  obtain  a  bucket;  second,  perform  the  appropriate  operation  on  that  bucket  to  get  a  new 
bucket;  and  third,  update  the  discrimination  function  so  that  all  domain  objects  which  used  to  map  to  the 
old  bucket  now  map  to  the  new  bucket  (i.e.  a  Newvalue  operation).  These  three  steps  are  expressed  by 
the  Diseriminatc+action+update  plan. 

Associative  Retrieval 

Associative  retrieval  adds  to  basic  set  operations  the  concept  of  a  key.  The  function  which 
associates  members  of  a  set  with  keys  is  called  the  key  function.  Given  a  set,  such  as  the  entries  in  a 
symbol  table,  we  are  often  more  interested  in  finding  a  member  with  a  given  key,  than  in  just  testing  for 
membership.  The  most  basic  specification  for  associative  retrieval  is  called  Retrieve  (see  bottom  of 
Fig.  3-3).  Given  a  set,  a  key  function  and  an  input  key.  Retrieve  has  two  cases:  if  there  exists  a  member  of 
the  set  with  the  given  key,  then  it  succeeds,  and  its  output  is  such  a  member;  otherwise  it  fails.  The  other 
common  associative  retrieval  specification.  Expunge,  removes  all  members  of  an  input  set  which  have  a 
given  key.  Expunge-onc  is  a  common  specialization  of  Expunge  which  often  allows  a  simpler 
implementation.  Expunge-one  has  the  additional  precondition  that  there  exists  exactly  one  member  of 
the  input  set  with  the  given  key. 

Keyed  Discrimination 

To  speed  up  associative  retrieval  for  a  given  key  function,  a  discrimination  function  can  be  used 
which  Is  itself  the  composition  of  two  functions.  This  is  the  data  plan  Keyed-discrimination  (see  middle  of 
figure).  The  first  function  is  the  key  function.  The  second  function,  called  the  bucket  function,  maps 
from  the  set  of  keys  to  the  buckets.  In  typical  usage,  the  bucket  function  may  itself  be  decomposed 
further  into  a  Hashing  (or  another  keyed  discrimination,  as  will  be  discussed  shortly). 

The  implementation  of  Retrieve  from  a  keyed  discrimination  has  the  same  two  step  structure  as  the 
implementation  of  Member?  for  a  discrimination:  first,  apply  a  function  to  obtain  a  bucket;  second, 
perform  the  appropriate  operation  on  the  bucket.  In  the  case  of  a  keyed  discrimination,  however,  the 
appropriate  bucket  is  obtained  by  applying  the  bucket  function  (which  is  the  second  half  of  the  composed 
functions  which  implement  the  discrimination)  to  a  given  key,  instead  of  applying  the  full  discrimination 
function  to  an  object  which  might  be  a  member  of  the  set.  This  plan  is  called  Keycd- 
diseriminatc+rctrieve. 
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For  Sct-add  and  Set-remove,  the  fact  that  a  discrimination  is  further  implemented  as  a  keyed 
discrimination  makes  no  difference. 

Associative  deletion  (Fxpunge)  from  a  keyed  discrimination  is  implemented  by  a  three  step 
temporal  plan.  Keyed-discriniinatc+expunge+update,  which  is  an  extension  of  the  Discriminate+action+ 
update  plan  described  earlier  (sec  figure).  Kcycd-discriminate+expunge+updatc  has  the  following  three 
steps.  (  This  plan  is  used  in  the  analysis  of  the  symbol  table  deletion  example.) 

(i)  First,  the  appropriate  bucket  is  obtained  by  applying  the  bucket  function  of  the  keyed 
discrimination  to  the  given  key. 

(ii)  Then,  just  as  in  Discriminatc+action+update,  the  action  on  the  whole  set  reduces  to  a 
corresponding  action  on  the  bucket.  The  Action  step  here  is  an  instance  of  F.xpunge. 

(iii) Thc  final  Update  step  is  similarly  a  Newvalue  operation  on  the  discrimination  function 
so  that  all  domain  objects  which  used  to  map  to  the  old  bucket,  map  to  the  new  bucket 
Furthermore,  in  the  case  of  a  keyed  discrimination,  only  the  bucket  function  needs  to  be 
updated;  the  key  function  stays  unchanged. 

The  idea  of  keyed  discrimination  can  be  generalized  to  multiple  key  data  bases  in  two  ways.  One 
approach  is  to  have  separate  discrimination  functions  for  each  key  function  which  map  into  a  shared  set 
of  buckets.  Associative  retrieval  on  a  pattern  of  keys  is  then  implemented  by  intersecting  the  appropriate 
buckets.  (This  is  the  idea  underlying  the  implementation  of  the  Connivcr  data  base  (451-)  Alternatively, 
the  discrimination  functions  for  different  keys  can  be  composed,  so  that  each  function  maps  to  a  bucket 
which  is  itself  a  set  implemented  as  a  discrimination  on  the  next  key.  ITiis  is  the  basic  idea  underlying 
discrimination  nets. 

3.4  Directed  Graphs 

Directed  graphs  arc  one  of  the  most  common  programming  data  structures.  A  Digraph  is  defined 
formally  in  the  library  as  a  set  of  nodes  and  an  edge  relation.  For  example,  a  Lisp  list  may  be  viewed  as  a 
directed  graph  wherein  the  nodes  arc  Lisp  cells,  the  edge  relation  is  Cdr,  and  Car  is  a  function  which 
attaches  a  label  to  each  node.  The  nodes  of  a  standard  I  .isp  binary  tree  structure  may  also  be  viewed  as  a 
directed  graph  in  which  the  edge  relation  is  the  union  of  the  Car  and  Cdr  relations  between  the  nodes. 
This  view  is  particularly  appropriate  for  programs  which  splice  objects  in  and  out  of  lists  or  trees. 

Barstow[6]  has  recently  developed  a  set  of  rules  for  generating  many  standard  programming 
algorithms  for  operating  on  directed  graphs  in  the  general  case.  Some  time  in  the  future  his  rules  should 
be  incorporated  into  the  present  library.  This  section  concentrates  on  the  special  case  of  acyclic  graphs 
with  a  single  root,  i.e.  trees,  and  furthermore  on  the  linear  case  of  trees,  which  are  here  called  threads. 

Fig.  3-4  shows  some  standard  specializations  of  Digraph.  Tree  is  a  directed  graph  in  which  there  is 
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figure  3-4.  Flans  Involving  Directed  Graphs. 
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a  root  and  no  cycles.1  A  Bintree  is  a  a  tree  in  which  each  node  is  cither  a  terminal  or  it  has  exactly  two 
successors.  A  Thread  is  a  specialization  of  Tree  in  which  the  successor  of  each  node  is  unique.  This  also 
means  that  the  predecessor  of  each  node  in  a  thread  (if  it  exists)  and  tire  terminal  node  arc  unique. 

The  vocabulary  of  partial  orders  is  often  applied  to  trees  and  threads.  For  example,  it  is  common  to 
think  of  a  nodes  in  a  tree  or  thread  being  "before"  other  nodes.  This  viewpoint  is  formalized  by  an 
overlay  from  Tree  to  Partial-order  indicated  in  Fig.  3-4.  A  tree  is  viewed  as  a  partial  order  in  which  two 
nodes  are  less  than  or  equal  iff  they  are  successor*  (the  transitive  closure  of  the  successor  relation)  in  the 
tree  or  arc  the  same  node.  The  root  of  the  tree  in  this  view  becomes  the  minimum  clement  of  the  partial 
order.  Furthermore,  if  the  tree  is  a  thread,  then  the  partial  order  is  total. 

Fig.  3-4  also  shows  an  overlay  between  Irrcdundant-Sequence  and  Thread.  An  irredundant 
sequence  can  be  viewed  as  a  thread  in  which  tire  first  term  of  the  sequence  corresponds  to  the  root  of  the 
thread  and  any  two  consecutively  numbered  terms  in  the  sequence  are  successors  in  the  thread.  Notice 
also  that  this  overlay  is  one-to-one,  which  means  that  for  each  instance  of  Thread  there  is  a  unique 
corresponding  instance  of  Irredundant-Sequcnce,  and  vice  versa.  This  allows  us  to  use  both  the  standard 
vocabulary  of  sequences  (such  as  length  and  the  idea  of  the  n-th  element)  and  of  directed  graphs  (such  as 
the  idea  of  successors)  as  appropriate  to  specify  properties  of  linear  structures. 

Generators 

* 

One  of  the  most  common  ways  of  implementing  directed  graphs  in  programming  is  to  specify  a 
single  node  (called  the  "seed")  and  a  binary  relation  such  that  the  nodes  of  the  desired  graph  are  the 
transitive  closure  of  the  given  node  under  the  given  relation.  This  implementation  is  captured  by  the  data 

plan  Generator. 

Iterator  is  the  specialization  of  Generator  which  generates  threads.  This  constrains  the  binary 
relation  of  an  iterator  to  be  many-to-onc  (i.e.  a  function)  and  to  have  no  cycles  within  the  transitive 
closure  of  the  seed.  This  data  plan  is  used  in  the  analysis  of  counting  loops  and  loops  which  cor  down  a 
list.  The  effect  of  the  generating  part  of  such  loops  is  abstracted  further  in  terms  of  the  input-output 
specification  Iterate,  which  takes  an  iterator  as  input  and  outputs  the  sequence  of  generated  nodes.  Loop 
plans  and  temporal  abstraction  will  be  discussed  further  in  the  next  section. 

Truncated  Directed  Graphs 

Another  common  way  of  specifying  a  directed  traph  is  as  part  of  another  directed  graph.  This  is 
particularly  used  for  specifying  finite  pans  of  infinite  graphs  such  as  intervals  of  the  natural  numbers. 

The  most  general  data  plan  describing  this  technique  is  Truncated-digra"h.  This  data  plan  has  two 
roles:  the  Base  graph  and  a  Criterion  predicate.  The  criterion  must  divide  the  nodes  of  the  base  graph 
into  three  sets:  a  set  of  boundary  nodes  which  satisfy  the  criterion;  interior  nodes,  from  which  boundary 

1.  Notice  that  this  definition  of  tree  docs  not  constrain  a  node  to  have  a  unique  predecessor,  i.e.  there  can  be  sharing  of 
substructure  in  the  tree.  In  later  versions  of  the  library  it  will  be  necessary  to  distinguish  between  acy  clic  rooted  directed  graphs  in 
which  nodes  do  and  do  not  haic  unique  predecessors. 
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nudes  can  be  reached  (in  a  finite  number  of  successor  steps);  and  exterior  nodes,  which  can  be  reached 
from  boundary  nodes.  When  the  base  graph  is  a  thread  (Truncated-thread),  this  means  more  simply  that 
some  node  of  the  thread  (cither  the  root  or  a  finite  successor  of  the  root)  satisfies  the  criterion.  Each  such 
criterion  thus  determines  a  finite  subgraph  of  interior  nodes,  either  including  or  not  including  the 
boundary  nodes. 

Examples  of  truncated  directed  graphs  in  Lisp  programming  are  Cdr  threads  truncated  by  the  Null 
predicate  and  Car-Cdr  binary  trees  truncated  by  the  Atom  predicate. 

A  closely  related  way  of  specifying  truncated  threads  is  in  terms  of  upper  and  lower  bounds  on 
some  total  order.  This  is  called  an  Interval  For  example,  the  integers  from  10  to  100  arc  specified  as  an 
instance  of  Interval  in  which  the  total  order  is  Le,  the  lower  bound  is  10,  and  the  upper  bound  is  100. 

Splicing  Plans 

Thinking  in  terms  of  directed  graphs  is  particularly  appropriate  for  understanding  programs  which 
add  or  remove  nodes  in  the  middle  of  lists  or  trees.  This  section  introduces  a  number  of  plans  related  to 
adding  or  removing  internal  nodes  of  threads  in  particular.  These  plans  arc  used  for  example  in  analyzing 
the  symbol  table  deletion  program. 

At  the  left  of  Fig.  3-4  arc  some  basic  input-output  specifications  on  directed  graphs  which  are 
involved  in  understanding  splicing  plans.  Digraph-add  is  the  basic  specification  for  adding  a  node  to  a 
directed  graph.  It  takes  an  old  graph  and  a  node  as  inputs  and  gives  a  new  graph  as  output.  All  that  can 
be  said  at  this  level  of  abstraction  is  that  the  input  is  a  node  of  the  new  graph,  and  that  all  the  successor 
relationships  in  the  graph  not  involving  either  the  added  node,  its  predecessors  or  successors  remain 
unchanged.  Digraph-add  docs  not  specify  where  in  the  directed  graph  the  node  is  to  be  added.  Internal- 
thread-add  is  a  specialization  of  Digraph-add  in  which  the  old  and  new  graphs  arc  threads  and  the  new 
node  is  added  anywhere  but  at  the  root. 

The  basic  input-output  specification  for  removing  a  node  from  a  directed  graph  is  Digraph-remove. 
Like  Digraph-add,  it  takes  an  old  graph  and  a  node  as  input,  and  returns  a  new  graph.  All  the  successor 
relationships  in  the  directed  graph  not  involving  the  removed  node  remain  unchanged.  The  successors  of 
the  removed  node  in  the  old  graph  become  the  successors  of  the  predecessor  of  the  removed  node  in  the 
new  graph.  Intemal-thrcad-remove  is  the  specialization  of  Digraph -remove  in  which  the  old  and  new 
graphs  are  threads  and  the  node  to  be  removed  is  not  the  root. 

Programs  which  splice  nodes  in  or  out  of  a  thread  typically  have  two  steps.  The  first  step  is  to  find 
the  place  in  the  thread  where  the  addition  or  removal  is  to  occur.  The  output  of  this  step  is  usually  a  pair 
of  successor  nodes,  such  that  either  the  new  node  is  to  be  added  between  them  or  the  second  node  is  the 
one  to  be  removed.  If  the  thread  is  implemented  as  an  iterator,  the  second  step  is  then  to  modify  the 
generating  function  so  as  to  cither  splice  in  or  splice  out  a  node,  as  the  case  may  be. 

The  input-output  specification  of  the  first  step  (finding  internal  nodes),  which  is  shared  between 
add  and  remove  programs,  is  called  Internal-thrcad-find.  Given  a  thread  and  a  criterion.  Internal-thread- 
find  returns  a  node  of  the  thread  (other  than  the  root)  which  satisfies  the  criterion,  and  its  predecessor. 
The  typical  implementation  of  this  specification  is  to  use  a  search  loop  which  keeps  track  of  both  the 


SPLICING  PLANS  47 


current  and  the  immediately  preceding  node.  This  loop  pattern  is  captured  by  the  recursive  temporal 
plan  Trailing-gcncration+search,  which  will  be  discussed  further  in  the  next  section. 

The  second  step  implementing  removal  of  a  node  is  a  Newarg  operation  in  which  the  association 
between  the  node  to  be  removed  and  its  predecessor  is  modified  to  be  an  association  between  the 
predecessor  and  the  successor  of  the  node  to  be  removed.  For  example,  in  the  bucket-delete  program  of 
the  scenario  in  Chapter  Two,  the  node  to  be  removed  is  in  p  and  its  predecessor  is  in  q;  the  generating 
function  is  cdr.  The  code  for  splicing  out  in  bucket-delete  is  as  follows.1 

(RPLACD  Q  (CDR  P) ) 

The  plan  for  this  form  of  code  in  general  is  called  Spliceout. 

The  second  step  implementing  addition  of  a  node  requires  two  Newarg  operations:  one  to  make 
the  new  node  point  to  its  successor,  and  one  to  make  the  predecessor  of  the  new  node  point  to  it  For 
example,  addition  of  a  node  to  a  Lisp  list  iterator  might  be  coded  as  follows. 

(RPLACD  NEW  CURRENT) 

(RPLACD  PREVIOUS  NEW) 

The  plan  for  this  form  of  code  in  general  is  called  Splicein. 

The  last  data  plan  in  Fig.  3-4  to  be  discussed  is  Labelled-digraph.  This  data  plan  has  two  roles: 
Spine  (a  digraph)  and  Label  (a  function  on  the  nodes  of  that  graph).  An  important  specialization  is 
Labelled-thread,  in  which  the  spine  is  further  constrained  to  be  a  thread.  This  plan  is  used  to  view  a  Lisp 
list  as  a  Cdr  thread  with  objects  attached  at  each  node  by  Car.  As  discussed  above,  this  view  is 
particularly  natural  for  understanding  programs  which  modify  lists  by  splicing. 

3.5  Recursive  Plans 

Recursively  defined  plans  are  used  in  the  plan  calculus  to  represent  unbounded  structures.  A 
recursive  plan  is  one  in  which  one  or  more  roles  are  constrained  to  be  instances  of  the  plan  itself.  This 
section  will  discuss  only  the  special  case  of  singly  recursive  plans,  since  the  plans  and  overlays  for  doubly 
and  multiply  recursive  structures  tend  to  be  long  and  more  detailed  than  those  for  singly  recursive 
structures,  without  introducing  any  fundamentally  new  ideas. 

At  the  top  of  the  hierarchy  of  recursive  plans  in  Fig.  3-5  is  a  minimal  plan.  Single-recursion,  which 
says  nothing  more  than  that  there  is  a  role,  Tail,  constrained  to  be  either  an  instance  of  Nil  or  itself  a 
Single-recursion.  Nil  is  a  distinguished  object  used  to  terminate  singly  recursive  structures. 

'I’he  most  important  singly  recursive  data  plan.  List,  will  be  discussed  first  in  the  following  section. 
Singly  recursive  temporal  plans,  e.g.  loops,  will  be  discussed  in  the  section  following  that.  Finally, 
temporal  abstraction  will  be  introduced  as  a  point  of  view  which  links  singly  recursive  temporal  plans  with 
singly  recursive  data  plans.  Chapter  Nine  treats  loops  and  temporal  abstraction  in  much  more  detail. 


1.  RPt  ACO  is  modelled  as  Newarg,  where  the  first  argument  to  RPLACD  is  the  domain  clement  and  the  second  argument  is  the  new 
range  element. 
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Lists 


List  is  a  singly  recursive  data  plan  with  two  roles.  Head  and  Tail.  The  head  may  be  any  object,  but 
the  tail  must  be  an  instance  of  List  or  Nil.  It  is  important  not  to  think  of  this  data  plan  too  concretely. 
The  List  plan  is  trying  to  capture  what  all  recursive  views  of  data  structures  have  in  common.  List  is  the 
point  of  view  which  is  used  for  making  (linear)  inductive  arguments  about  data  structures.  Thus  the 
reader  should  not  identify  the  data  plan  List  too  closely  with,  for  example,  the  Lisp  list  Think  of  the  data 
plan  List  as  if  it  were  called  "singly  recursive  data  structure”. 

Two  basic  input-output  specifications  on  lists  are  shown  at  the  top  left  of  Fig.  3-5.  Push  takes  as 
input  a  list  (or  Nil)  and  an  object,  and  returns  a  new  list,  whose  tail  is  the  input  list  and  whose  head  is  the 
input  object.  Pop  takes  a  list  and  returns  its  head  and  tail  as  its  two  outputs. 

A  common  implementation  of  lists  is  to  use  a  sequence  (e.g.  an  array)  with  an  index  to  where  the 
current  head  is  stored.  The  data  plan  which  captures  this  implementation  is  called  Upper-segment.  This 
plan  is  a  specialization  of  Segment,  which  has  three  roles:  the  Base,  which  is  a  sequence,  and  the  Upper 
and  Lower  bounds,  which  must  be  valid  indices  for  the  base.  Upper-segment  is  a  specialization  of 
Segment  in  which  the  upper  bound  is  equal  to  the  length  of  the  base  sequence.  Push  and  Pop  operations 
on  this  implementation  are  implemented  by  the  two-step  temporal  plans,  Bump+update  and 
Fctch+update,  respectively.  The  second  step  in  each  of  these  plans  is  either  to  add  or  subtract  one  from 
the  old  lower  bound  to  get  a  new  lower  bound.1  The  first  step  in  implementation  of  Push  is  a  Ncwterm 
operation,  which  makes  the  given  object  the  head  of  the  new  list  The  first  step  in  the  implementation  of 
Pop  is  a  Term  operation,  which  fetches  the  current  head  of  the  list 

Multiple  Views  of  Linear  Structures 

Fig.  3-5  also  indicates  overlays  between  lists  and  other  linear  structures,  such  as  sequences  and 
threads.  For  example,  whether  a  given  data  structure  is  viewed  as  a  list  or  as  a  sequence  depends  on  what 
we  want  to  say  about  it.  Certain  properties  are  easier  to  specify  inductively,  in  which  case  the  list  view  is 
appropriate.  In  other  cases,  explicit  quantification  over  the  indices  of  a  sequence  is  more  convenient  In 
the  overlay  between  List  and  Sequence,  the  head  of  the  list  corresponds  to  the  first  term  of  the  sequence, 
and  the  head  of  the  n-tlt  tail  of  the  list  corresponds  to  the  (n  + 1  ^th  term  of  the  sequence. 

In  the  overlay  between  List  and  Labelled-thread,  the  nodes  of  the  spine  of  the  thread  arc  the  list 
and  all  of  its  tails.  The  edge  function  on  the  nodes  of  the  spine  is  the  Tail  function,  and  the  label  function 
is  Head.  Thus  we  now  have  two  ways  of  viewing  Lisp  cells  which  have  Lisp  cells  or  Nil  as  their  Cdr.  We 
can  view  such  a  Lisp  cell  as  implementing  a  list  in  which  the  Car  of  the  cell  is  its  head  and  the  Cdr  is  its 
tail;  or  we  can  view  the  same  Lisp  cell  as  the  seed  for  generating  a  Cdr  thread  which  is  labelled  by  Car. 


1.  Again,  it  this  level  of  abstraction  no  commitment  is  made  in  these  plans  as  to  whether  the  instance  of  Upper-segment  is 
modified  by  side  effect  or  copied.  These  arc  treated  as  specialisations,  just  as  the  "pure"  and  "impure"  versions  of  Push  and  Popart 
treated  as  specializations. 
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Linear  structures  may  also  be  viewed  as  (i.e.  implement)  sets.  In  particular,  a  list  may  be  viewed  as 
the  set  whose  members  are  the  head  of  the  list  unioned  with  the  tail  of  the  list  viewed  as  a  set-  Nil  is 
usually  viewed  as  the  empty  set.  In  this  view,  neither  the  order  of  occurrence  of  elements  in  the  list  nor 
the  occurrence  of  duplicates  matters.  In  this  view,  Push  and  Pop  operations  on  a  list  arc  implementations 
of  Set-add  and  Set-remove  operations.  Alternatively,  viewing  lists  as  labelled  threads,  Set-add  and  Set- 
remove  may  be  implemented  by  Splicein  and  Spliccout  plans.  Both  of  these  points  of  view  are  needed  to 
understand  how  entries  are  added  and  removed  in  the  symbol  table  example:  in  symbol-table -ado 
entries  are  added  to  the  bucket  by  a  Push  operation  (implemented  in  Lisp  by  cons);  in  bucket-delete 
entries  are  removed  by  a  Spliceout  plan  (implemented  in  Lisp  using  rplaco). 

Loops 

The  taxonomy  of  loop  structures  used  in  the  library  is  based  on  Waters’  [73]  method  for  analyzing 
loop  programs.  Waters’  method  decomposes  loops  into  fragments  which  correspond  to  "easily 
understood  stereotyped  fragments  of  looping  behavior."  The  next  section  describes  overlays  which  allow 
these  fragments  to  be  logically  composed,  rather  than  interleaved  (as  they  are  in  an  unanalyzed  loop), 
which  makes  their  net  effect  easier  to  understand.  For  example,  consider  the  following  program,  which 
sums  up  the  non-nil  elements  of  a  list 

(DEFINE  SIGMA 
(LAMBDA  (L) 

(PROG  (S  N) 

(SETQ  S  0) 

LP  (C0N0  ((NULL  L)(RETURN  S) ) } 

(SETQ  N  (CAR  L) ) 

(COND  (N  (SETQ  S  (PLUS  S  N) ) ) ) 

(SETQ  L  (COR  L) ) 

(GO  LP)))) 

Waters  distinguishes  three  types  of  fragments  (he  calls  them  plan  building  methods)  in  loops  with 
one  exit  test.  The  first  type  he  calls  "basic  loops".  A  basic  loop  is  characterized  by  the  fact  that  all  of  the 
computation  in  the  body  of  the  loop  can  potentially  affect  the  termination  of  the  loop.  For  example,  the 
basic  loop  part  of  sigma  is  the  following. 

(LAMBDA  (L) 

(PROG  (...) 

LP  (C0N0  ((NULL  l)...)) 

(SETQ  L  (COR  L)) 

(GO  LP))) 

Basic  loops  arc  further  decomposed  into  a  generation  part  (e.g.  the  part  involving  cdr  above)  and  a 
termination  part  (e.g.  the  null  test  above).  The  temporal  plan  which  captures  the  form  of  the  generating 
part  of  loops  in  general  is  called  Iterative-generation.  The  plan  which  captures  the  form  of  single  exit 
tests  is  called  Iterative-termination.  Both  of  these  arc  extensions  of  Single-recursion  (sec  Fig.  3-5).  The 
advantage  of  this  further  decomposition  is  it  allows  us  to  capture  the  similarity  between  loops  which  have 
the  same  generation  part  hut  different  terminations.  For  example,  one  can  form  many  different  loops 
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with  Counting  as  the  generation  part,  but  with  different  terminations.  (Counting  is  a  a  specialization  of 
Iterative-generation  in  which  the  generating  function  is  Oneplus) 

Waters’  second  category  of  plan  building  method  is  called  "augmentations".  Augmentations  are 
characterized  by  the  fact  that  they  consume  values  produced  by  other  parts  of  the  loop  and  produce 
values  which  may  be  used  by  other  augmentations.  In  the  library,  augmentations  are  further  divided  into 
application  and  accumulation.  The  distinction  between  these  two  types  of  augmentations  rests  on  whether 
there  is  any  "feedback",  i.e.  whether  the  augmentation  consumes  its  own  values  from  previous  iterations 
—  accumulation  does,  application  docs  not.  For  example,  the  following  is  the  application  part  of  sigma. 

(PROG  (...N) 

LP  III 

(SETQ  N  (CAR  L)) 

(GO  LP)) 

The  plan  for  this  form  of  code  in  general  is  called  Iterative-application,  sigma  also  has  an  example 
of  accumulation,  as  shown  below. 

(PROG  (S...) 

(SETQ  S  0) 

LP  ...(RETURN  S)... 

...(SETQ  S  (PLUS  S  ...))... 

(GO  LP)) 

Tiie  plan  for  this  form  of  code  in  general  is  called  Iterative-accumulation.  Three  common 
specializations  of  Iterative-accumulation  are  shown  in  Fig.  3-5.  Itcrative-sct-accumulation  is  a 
specialization  in  which  the  accumulation  operation  (e.g.  plus  above)  is  Set-add  and  the  initial 
accumulation  is  the  empty  scL  Iterative-list-accumulation  is  a  specialization  in  which  the  accumulation 
operation  is  Push  and  the  initial  accumulation  is  Nil.  Iterative-aggregation  is  a  specialization  in  which  the 
accumulation  operation  is  the  application  of  an  aggregative  function  (as  discussed  earlier  in  the  section  on 
functions)  and  the  initial  accumulation  is  the  identity  element  for  that  function. 

Waters’  final  type  of  plan  building  method  is  called  "filtering”.  It  is  the  special  case  of  an 
augmentation  whose  body  is  a  conditional.  The  purpose  of  filtering  usually  is  to  restrict  the  values  that 
will  be  consumed  by  some  other  augmentation.  For  example,  in  sigma  the  following  is  the  filtering  part 
of  the  loop  which  restricts  the  accumulation  part  to  consuming  only  the  non-nil  inputs. 

*  (PROG  (...*) 

•  •  • 

LP  ... 

(COND  (N  ...) 

(GO  LP)) 

The  plan  for  this  form  of  code  in  general  is  called  Iterative-filtering. 
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Finally,  the  Trailing-gencration+search  plan  at  the  bottom  of  Fig.  3-5  illustrates  an  important 
feature  of  the  taxonomy  in  the  library,  namely  that  it  is  a  tangled  hierarchy.  Trailing-gcneration+search 
combines  the  features  of  three  plans.  One  of  these  plans  is  Iterative-generation,  an  example  of  which  is 
the  following. 

(PROG  (P  ...) 

LP  (SETQ  P  (COR  P)) 

(GO  LP)) 

The  second  plan  is  Iterative-search.  Iterative-search  is  a  specialization  of  Iterative-termination 
wherein  the  exit  test  is  the  application  of  a  predicate  which  doesn’t  change  as  the  computation  proceeds, 
and  in  which  the  final  object  which  satisfied  the  exit  test  is  available  outside  the  loop.  This  plan  is 
suggested  by  the  following  code. 

(PROG  (P  ...) 

LP  !!! 

(COMO  (,..P... 

. .  ,P. • • 

(RETURN  ...))) 

(GO  LP)) 

The  final  plan  is  Trailing,  which  captures  the  idea  of  keeping  track  of  the  immediately  previous 
value  of  some  loop  variable,  as  suggested  by  the  following  code. 

(PROG  (P  Q) 

LP  (SETQ  P  ...) 

(SETQ  Q  P) 

(GO  LP)) 

Tailing-generation+scarch  inherits  the  roles  and  constraints  of  all  three  of  these  plans.  For  example, 
the  combination1  of  the  three  example  fragments  above  gives  the  essential  loop  structure  of 
bucket-delete,  as  shown  below. 

(PROG  (P  Q) 

(SETQ  Q  BUCKET) 

LP  (SETQ  P  (COR  Q)) 

(COND  ((EQUAL  (CAAR  P))  INPUT) 

(RPLACO  Q  (COR  P) )  ;SPLICE  OUT. 

(RETURN  BUCKET)) 

(SETQ  Q  P) 

(GO  LP)) 


1.  The  code  fragments  above  cannot  literally  be  combined  to  get  the  loop  of  BUCKET-DELETE.  The  appropriate  domain  for  this 
combination  is  the  plan  calculus. 
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Temporal  Abstraction 

The  basic  idea  of  temporal  abstraction  is  to  view  all  the  objects  which  fill  a  given  role  at  each  level 
in  a  recursive  temporal  plan  as  a  single  data  structure.  In  programming  language  terms,  this  often 
corresponds  to  having  an  explicit  representation  for  the  sequence  of  values  taken  on  by  a  particular 
variable  at  a  particular  point  in  a  loop.  This  idea  is  also  present  in  the  work  of  both  Waters  [73J  and 
Shrobe  [64 J.  Using  temporal  abstraction,  the  recursively  defined  plan  for  a  loop  can  be  viewed  much 
more  simply  as  a  simple  composition  of  operations  on  sequences  or  sets.  Chapter  Nine  explains  how  this 
analysis  is  formalized  using  overlays  for  the  various  loop  plans  described  in  the  preceding  section. 

Fig.  3-5  shows  some  of  these  overlays.  For  example.  Iterative-generation  can  be  temporally 
abstracted  as  Iterate.  The  input  to  Iterate  in  this  overlay  is  an  iterator  whose  seed  is  the  initial  value  of  the 
relevant  loop  variable  (e.g.  ?  above)  and  whose  generating  function  is  the  function  applied  each  time 
around  the  loop  (e.g.  cor  above).  The  output  of  Iterate  corresponds  to  the  sequence  of  values  taken  on 
by  the  loop  variable. 

The  relationship  between  the  sequences  of  values  consumed  and  produced  in  an  instance  of 
Iterative-application  can  similarly  be  viewed  as  a  Map  operation.  In  programs  where  order  and 
occurrence  of  duplicates  in  the  loop  values  doesn’t  matter,  a  further  temporal  abstraction  can  be  made  by 
viewing  the  values  consumed  and  produced  as  sets.  In  this  view,  Iterative-application  implements  Each. 

Similarly,  Iterative-search  can  be  viewed  as  implementing  either  Earliest  or  Any,  depending  on 
whether  the  inputs  over  time  to  the  exit  tests  are  viewed  as  a  sequence  or  a  set;  and  Iterative-filtering  can 
be  v  iewed  as  the  implementation  of  Restrict 
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CHAPTER  FOUR 
THE  PLAN  CALCULUS 


4.1  Introduction 

The  purpose  of  this  chapter  is  to  give  an  intuitive  definition  of  the  plan  calculus.  (A  formal 
definition  is  given  in  Chapter  Eight.)  Practically  speaking,  the  plan  calculus  is  a  network-like  formalism. 
This  chapter  introduces  a  diagram  notation  which  will  be  used  to  define  and  describe  the  use  of  plans  in 
succeeding  chapters.  There  are  many  well-known  ways  of  storing  such  networks  in  a  computer  to 
facilitate  various  kinds  of  updating  and  retrieval.  Concrete  storage  representations  of  the  plan  calculus 
will  therefore  not  be  discussed  here.  Several  different  concrete  storage  representations  have  been 
implemented  and  used  by  the  author,  Shrobc  |64]  and  Waters  (72]. 

The  plan  calculus  has  two  major  components:  plans  and  overlays.  The  first  part  of  this  chapter 
introduces  plan  diagrams,  followed  by  a  discussion  of  the  relationship  between  such  diagrams  and  the 
Lisp  code  for  a  program.  The  second  pan  pan  of  this  chapter  introduces  overlay  diagrams,  followed  by 
some  general  observations  on  the  use  of  overlays  as  a  preview  of  coming  chapters. 

Side  effects  and  mutable  objects  will  only  he  mentioned  in  passing  in  this  chapter,  since  a  proper 
discussion  requires  the  formal  foundations  developer*  >t  Chapter  Eight.  Plans  involving  side  effects  are 
also  discussed  further  in  Chapter  Eight 

4.2  Plans 

The  basic  idea  of  a  plan  in  the  plan  calculus  comes  from  an  analogy  between  programming  and 
other  engineering  activities  (54].  "Plans '  of  various  kinds  are  used  by  many  different  kinds  of  engineers. 
For  example,  an  electrical  engineer  uses  circuit  diagrams  and  block  diagrams  at  various  levels  of 
abstraction;  a  structural  engineer  uses  large-scale  and  detailed  blue  prints  which  show  both  the 
architectural  framework  of  a  building  and  also  various  subsystems  such  as  heating,  wiring  and  plumbing; 
a  mechanical  engineer  uses  overlapping  hierarchical  descriptions  of  the  interconnections  between 
mechanical  parts  and  assemblies. 

A  fundamental  characteristic  shared  by  all  these  types  of  engineering  plans  is  that  at  each  level  there 
is  a  set  of  parts  with  constraints  between  them.  Sometimes  these  parts  correspond  to  discrete  physical 
components,  such  as  transistors  in  a  circuit  diagram,  but  more  often  the  decomposition  is  in  terms  of 
function.  For  example,  a  simple  amplifier  in  an  electrical  block  diagram  has  the  functional  description 
V2 = kVf,  where  Vj  and  Vj  arc  the  input  and  output  signals,  and  k  is  the  amplification  factor.  As  far  as 
this  level  of  plan  is  concerned  the  amplification  may  be  rcali/.cd  in  any  number  of  ways.  A  primitive 
component  may  be  used  or  another  plan  may  be  provided  which  decomposes  the  amplifier  further. 
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By  analogy,  plans  in  programming  specify  the  parts  of  a  computation  and  constraints  between 
them.  In  the  plan  calculus,  the  names  of  the  parts  of  a  computation  are  called  roles.  It  is  natural  to  think 
of  roles  as  selector  functions.  For  example,  consider  the  Segment  plan  discussed  in  Chapter  One,  which 
has  three  roles  named  Base,  Upper  and  Lower.  To  refer  to  the  Base  sequence  of  this  plan  we  write 
Segmcnt.Base,  to  refer  to  the  Upper  index  we  write  Segment.Upper,  and  so  on.  lhe  point  (".")  in  this 
notation  has  the  same  intuitive  meaning  as  in  its  use  for  selecting  fields  of  record  structures  in 
programming  languages  such  as  PL/1. 

An  expression  with  a  point  in  it  is  called  a  path  name.  If  a  role  is  filled  by  an  instance  of  another 
plan,  the  point  notation  can  be  used  several  times.  For  example,  consider  a  plan  named  Bump+update 
which  has  a  role  named  Old,  constrained  to  be  a  Segment  The  path  name  Bump+update.01d.Upper  then 
refers  to  the  upper  index  of  the  Old  segment  of  the  plan. 

All  composite  plans  are  composed  (using  roles  and  constraints)  out  of  three  primitives  types: 
input-output  specifications,  test  specifications  and  primitive  object  types  (integers,  sets  and  functions). 
Plans  composed  up  exclusively  out  of  objects  are  called  data  plans.  Plans  composed  of  objects,  test  and 
input-output  specifications  are  called  temporal  plans. 

Input-Output  Specifications 

An  example  of  an  input-output  specification  is  shown  at  top  of  Fig.  4-1.  An  input-output 
specification  is  drawn  as  a  solid  rectangular  box  with  solid  arrows  entering  at  the  top  and  leaving  the 
bottom.  Each  arrow  entering  at  the  top  represents  an  input;  each  arrow  leaving  the  bottom  represents  an 
outpuL  Each  input  and  output  has  a  role  name.1  For  example,  the  input-output  specification  depicted  in 
Fig.  4-1,  Ncwterm,  has  three  inputs,  named  Old,  Arg  and  Input;  and  one  output,  named  New. 

Input-output  specifications  also  have  preconditions  and  postconditions.  The  preconditions  involve 
only  the  inputs;  the  postconditions  involve  both  the  inputs  and  the  outputs.  The  simplest  kind  of  such 
conditions  arc  restrictions  on  the  type  of  each  role  individually.  These  are  usually  indicated  in  plan 
diagrams  in  parentheses  after  the  role  name.  For  example,  in  Fig.  4-1  we  see  that  Newterm.01d  is 
expected  to  be  a  sequence;  and  that  Newtcrm.Arg  is  expected  to  be  a  natural  number.  Object  as  a  type 
restriction,  as  for  Newtcrm.Input,  means  that  there  is  no  more  specific  restriction  on  the  given  role. 

In  this  chapter  and  the  following  three,  constraints  between  the  inputs  and  outputs  of  an  input- 
output  specification  will  be  described  informally  in  English,  as  they  are  relevant  to  the  current  discussion. 
For  example,  all  the  terms  of  Newterm.Ncw.  arc  constrained  to  be  identical  to  the  corresponding  terms  of 
Newtcrm.Old,  except  for  the  Ncwtcrm.Argf/i  term  which  is  equal  to  Newtcrm.Input.  The  interested 
reader  may  refer  to  the  appendix  for  a  formal  statement  of  the  preconditions  and  postconditions  of  any 
particular  input-output  specification  (use  index  to  find  page  number).  These  constraints  arc  written  in  a 
standard  logical  language  defined  in  Chapter  Eight 


1.  In  this  chapter  input-output  specifications  arc  primitive.  In  Chapter  Light,  however,  input-output  specification  specifications 
arc  treated  formally  as  composite  plans  whose  pans  arc  objects  and  situations.  This  is  why  the  inputs  and  outputs  arc  roles. 
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Figure  4- 1.  An  Input-Output  Specification  and  a  Test  Specification. 
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To  reduce  the  clutter  in  more  complicated  plan  diagrams  later  in  this  document,  some  information 
will  be  omitted  when  it  can  easily  be  inferred  by  the  reader.  For  example,  type  restrictions  (especially 
Object)  will  often  be  omitted  for  input-output  specifications  which  should  be  familiar  by  that  point  in  the 
discussion.  Input  and  output  role  names  will  also  sometimes  be  omitted,  in  which  case  the  same  left-to- 
right  order  used  when  the  specification  was  first  defined  (which  is  also  listed  in  the  appendix)  is  to  be 
assumed. 

Test  Specifications 

A  test  specification  is  drawn  as  a  solid  rectangular  box  with  a  divided  bottom  section,  as  shown  in 
the  lower  part  of  Fig.  4-1.  The  inputs  and  outputs  of  a  test  specification  are  notated  in  the  same  way  as 
the  inputs  and  outputs  of  an  input-output  specification.  For  example,  the  test  show  n  in  Fig.  4-1,  has  two 
inputs,  named  Universe  (a  set)  and  Criterion  (a  predicate),  and  one  output  named  Output  (an  object).  A 
test  also  has  preconditions  and  postconditions,  just  like  an  input-output  specification. 

A  test  specification  differs  from  an  input-output  specification  in  that  two  distinct  output  situations 
are  specified.  Which  one  occurs  depends  on  whether  or  not  a  given  relation  (called  the  condition  of  the 
test)  holds  true  between  the  inputs.  If  the  test  condition  is  true,  then  the  test  is  said  to  succeed  and  the 
outputs  indicated  on  the  "S"  side  of  the  box  are  available;  otherwise  the  test  is  said  to  fail,  and  the  outputs 
indicated  on  the  "F"  side  of  the  box  are  available.  For  example,  the  test  specification  Any  shown  in 
F'ig.  4-1  succeeds  if  there  exists  a  member  of  Any.Universe  which  satisfies  Any. Criterion,  in  which  case 
Any.Output  is  such  an  object;  otherwise  it  fails  and  there  is  no  output.1 

More  complicated  tests  with  more  than  two  cases  can  be  represented  by  composing  binary  tests. 
Alternatively,  the  test  notation  is  gencralizable  to  more  than  two  cases. 

As  with  input-output  specifications,  the  preconditions,  postconditions  and  test  conditions  of  test 
specifications  in  the  following  three  chapters  will  be  described  informally  in  English  in  the  text  and 
formally  in  the  appendix. 

Control  Flow 

Fig.  4-2  shows  how  control  flow  arcs  (hatched  arrows)  are  used  to  connect  input-output  and  test 
specifications  to  specify  conditional  behavior.  This  plan,  called  Cond,  is  the  basic  "if-thcn-else”  construct 
in  the  plan  calculus.  Cond.lf  is  restricted  to  be  an  instance  of  Test,  which  is  the  minimal  test 
specification,  i.e.  all  other  test  specifications  are  extensions  of  Test  Cond.Then  and  Cond.Else  are 
restricted  to  be  instances  of  In+Out,  which  is  the  minimal  input-output  specification.  Note  that  the 
definition  of  In+out  allows  a  degenerate  action  of  doing  nothing,  so  that  conditionals  with  only  one 
branch  may  be  represented. 


1.  Note  that  at  this  level  of  abstraction,  no  commitment  is  made  as  to  whether  or  not  this  test  modifies  its  inputs.  This  constraint  is 
added  when  necessary  in  a  plan  in  which  an  Any  test  is  used. 
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The  F,nd  role  of  Cond  introduces  a  third  primitive  closely  related  to  input-output  and  test 
specification,  namely  join  specifications.1  Joins  arc  the  mirror  image  of  tests.  A  join  specification  is 
drawn  as  a  solid  rectangular  box  with  the  top  part  divided  into  "S"  and  "F"  parts,  corresponding  to  the 
succeed  and  fail  cases  of  the  matching  test.  Unlike  tests,  however,  joins  do  not  represent  any  real 
computation.  Joins  are  a  technical  artifact  used  to  rejoin  the  two  branches  of  a  conditional  block,  as  in 
Cond.  Join  is  the  minimal  join  specification. 

An  extension  of  Join,  called  Join-output,  will  be  shown  later.  In  addition  to  joining  control  flow. 
Join-output  has  input  and  output  roles  which  specify  the  connection  between  which  branch  of  a 
conditional  is  executed  and  which  of  two  possible  inputs  is  made  available  for  further  computation.  For 
example,  in  the  following  code  the  input  to  c  comes  either  from  a  or  from  b  depending  on  the  test  P. 

(C  (COND  ((P  ...)  (A  ...)) 

(T  (B  ...)))) 


Data  Flow 

Intuitively,  data  flow  specifies  equality  between  two  data  roles  in  a  temporal  plan,  especially 
between  the  output  of  one  input-output  specification  or  test  and  the  input  of  another.  Data  flow  is 
indicated  in  plan  diagrams  by  solid  arrows,  as  shown  in  Fig.  4-3. 

Fig.  4-3  shows  the  plan  for  the  standard  implementation  of  a  membership  test  (Member?)  on  a  set 
implemented  as  a  discrimination  function.  This  plan  has  two  roles:  Discriminate  and  If.  The 
Discriminate  role  is  restricted  to  be  an  instance  of  ©Discrimination.  (©Discrimination  is  a  specialization 
of  ©Function  in  which  the  Op  is  a  discrimination  function  and  the  Output  is  therefore  a  set.)  The  If  role 
is  restricted  to  be  an  instance  of  Member?,  which  tests  whether  the  Input  is  a  member  of  the  Universe  set. 

The  data  flow  arc  between  Discriminate.Output  and  If.Universc  in  the  plan  of  Fig.  4-3  means  that 
the  Universe  of  the  test  is  the  same  as  output  of  the  Discriminate  operation.  This  data  flow  arc  does  not 
mean,  however,  that  the  test  must  immediately  follow  the  Discriminate  operation.  An  arbitrary  amount 
of  computation  may  occur  between  the  end  of  the  Discriminate  operation  and  the  beginning  of  the  test, 
as  long  as  the  set  involved  is  the  same  at  the  time  the  test  begins  as  when  the  Discriminate  operation 
ended. 

Temporal  Plans 

Fig.  4-3  is  an  example  of  a  temporal  plan.  Such  plans  in  general  have  roles  which  arc  input-output, 
test  and  join  specifications  with  data  flow  and  control  flow  constraints  between  them.  Temporal  plans  are 
drawn  with  a  dashed  box  enclosing  the  boxes  which  define  the  roles.  A  very  natural  way  of 
understanding  the  meaning  of  such  diagrams  in  terms  of  the  propagation  of  data  and  control  tokens 
through  the  acyclic2  directed  graph  of  data  and  control  arcs.  This  model  is  essentially  the  one  used  in 
data  flow  schemas  119). 


1.  Joins  were  introduced  into  the  plan  calculus  by  Waters  [73). 

2.  1-oops  arc  represented  as  tail  recursions. 
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Figure  4*3.  A  Temporal  Plan  With  Data  How. 
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In  the  token  propagation  model  of  temporal  plans,  control  flow  arcs  are  treated  no  differently  than 
data  flow  arcs.  When  an  input-output  box  has  received  tokens  on  all  of  its  incoming  arcs,  it  is  "activated" 
and  generates  tokens  with  the  appropriate  properties  (according  to  its  input-output  specifications)  on  all 
of  its  outgoing  arcs.1  If  an  output  goes  to  the  inputs  of  several  other  boxes  (i.c,  an  arc  splits  along  its  way 
into  two  or  more  arcs),  then  tokens  passing  over  that  arc  are  duplicated  the  appropriate  number  of  times 
so  that  the  same  object  is  available  at  each  input  location.  Control  flow  tokens  have  no  properties;  their 
only  function  is  to  enable  activitation. 

A  test  box  is  activated  the  same  way  as  an  input-output  box,  i.e.  when  it  has  received  tokens  on  all 
of  its  incoming  arcs.  It  then  generates  tokens  either  on  all  of  the  arcs  leaving  the  success  side  of  the  box, 
or  on  all  those  leaving  the  failure  side,  depending  on  the  properties  of  the  incoming  objects.  A  join  has 
the  complementary  behavior.  It  is  not  activated  until  it  has  received  all  the  tokens  on  one  or  the  other 
input  side.  It  then  generates  all  its  output  tokens  with  properties  according  to  its  specifications  (since 
joins  involve  no  computation,  the  output  tokens  are  always  the  identical  to  the  input  tokens). 

Data  Plans 

Data  plans  are  plans  whose  roles  are  restricted  to  primitive  data  objects  or  other  data  plans.  Data 
plans  are  drawn  as  dashed  ovals.  Primitive  data  objects  are  drawn  as  solid  ovals.  For  example,  the  data 
plan  Segment,  shown  in  Fig.  4-4,  has  three  roles  named  Base,  Upper  and  Lower,  restricted  to  be  a 
sequence  and  two  natural  numbers,  respectively.  The  constraints  between  roles  are  that  die  Upper  and 
Lower  numbers  are  each  less  than  or  equal  to  the  length  of  the  Base  sequence,  and  that  the  Lower 
number  is  less  than  or  equal  to  the  Upper  number.  (Again,  these  constraints  are  written  formally  in  a 
logical  language,  the  details  of  which  are  being  suppressed  until  Chapter  EighL) 

Recursive  Plans 

Recursion  in  plan  diagrams  is  indicated  by  a  spiral  line  as  shown  in  Fig.  4-5.  The  minimal  singly 
recursive  plan  is  called  Single-recursion.  It  has  only  one  role.  Tail,  which  is  constrained  to  be  an  instance 
of  itself.  All  other  singly  recursive  plans  are  extensions  of  Single-recursion. 

For  example,  the  singly  recursive  plan  in  Fig.  4-5,  called  Iterative-Generation,  describes  a  part  of  a 
loop  in  which  on  each  iteration  some  function  (Action.Op)  is  applied  to  an  input,  with  the  resulting 
output  becoming  the  input  to  the  application  (Tail. Action)  of  the  same  function  on  the  next  iteration. 
The  following  code  fragment  suggests  such  a  computation  in  which  the  Action  is  CDR. 

(PROG  (L) 

LP  ... 

(SETQ  L  (COR  L>) 

(GO  LP)) 


1.  Thus  all  input-output  specifications  require  termination. 
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Figure  4-4.  A  Data  Plan. 
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Figure  4-5.  A  Recursive  Plan. 
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4.3  Surface  Plans 


In  conventional  programming  languages,  such  as  Lisp,  Fortran  or  PL/1,  it  is  possible  to  construct 
many  different  programs  which,  from  the  point  of  view  of  the  plan  calculus,  specify  the  same 
computations.  Difference  in  the  names  of  variables  is  the  most  trivial  example  of  this  kind  of 
uninteresting  variability.  Most  programming  languages  also  provide  many  different  mechanisms  for 
achieving  the  flow  of  data  from  one  operation  to  another.  For  example,  in  Lisp  we  could  write  either 


(SETQ  X  (F  ...)) 
(fi*X) 


or 


(G  (F  ...))  . 


Similarly,  the  following  two  constructions  specify  essentially  the  same  control  flow. 


(PROG  (...) 

LP  (COND  (P  (RETURN  NIL))) 

(GO  LP)) 

(PROG  (...) 

LP  (CONO  (P) 

(T  ... 

(GO  LP)))) 


Combining  all  three  of  these  kinds  of  superficial  variation,  we  can  construct  the  following  two  versions  of 
the  code  for  bucket-retrieve  (the  first  version  is  from  the  scenario),  which  illustrate  how  different  the 
same  program  can  appear.  Part  of  the  advantage  of  the  plan  calculus  over  programming  languages  for 
our  purposes  is  that  both  of  these  versions  translate  to  the  same  surface  plan  (shown  in  Chapter  Five). 


(DEFINE  8UCKET -RETRIEVE 
(LAMBDA  (BUCKET  INPUT) 

(PROG  (OUTPUT) 

IP  (CONO  ((NULL  8UCKET)( RETURN  NIL))) 
(SETO  OUTPUT  (CAR  BUCKET)) 

(COND  ((EQUAL  (CAR  OUTPUT)  INPUT) 
(RETURN  OUTPUT))) 

(SETQ  BUCKET  (CDR  BUCKET)) 

(GO  LP)))) 


(DEFINE  BUCKET-RETRIEVE 
(LAMBDA  (BKT  KEY) 

(PROG  (ENTRY) 

LP  (COND  ((NULL  BKT)) 

((EQUAL  (CAR  (SETQ  ENTRY  (CAR  BKT)))  KEY) 
(RETURN  ENTRY)) 

(T  (SETQ  BKT  (CDR  BKT)) 

(GO  LP)))))) 
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From  the  standpoint  of  program  analysis,  a  surface  plan  can  be  thought  of  as  an  abstraction  of  the 
data  flow  and  control  flow  in  a  program,  without  abstracting  the  primitive  data  structures  and  operations. 
From  the  standpoint  of  program  synthesis,  a  surface  plan  is  the  lowest  level  representation  of  the  program 
design,  which  is  then  translated  to  code  in  a  standard  programming  language. 

Programming  Language  Semantics 

In  order  to  translate  between  a  given  programming  language  and  surface  plans,1  the  primitives  of 
the  programming  language  arc  divided  into  two  categories:  connectives,  such  as  prog,  cond,  setq,  go  and 
return  in  Lisp,  which  are  concerned  solely  with  implementing  data  and  control  flow;  and  the  objects, 
relations,  and  actions  of  the  language,  such  as  numbers,  dotted  pairs,  arithmetic  relations,  car,  cdr  and 
cons.  The  first  category  of  primitives  is  translated  into  the  pattern  of  control  and  data  flow  arcs  (including 
tests  and  joins)  between  other  specifications  defined  in  terms  of  the  second  category  of  primitives. 

The  translation  of  the  second  category  of  primitives  (i.e.  non-connectives)  into  the  plan  calculus  is 
done  in  three  steps,  each  of  which  involves  some  judgement  The  first  step  is  to  identify  a  set  of  basic 
object  types  in  the  language.  For  example.  Lisp  can  be  viewed  as  having  four  basic  types  of  objects: 
atoms,  dotted  pairs,  vectors,  and  integers.2 

The  next  step  is  to  choose  an  appropriate  set  of  primitive  relationships  between  objects.  For 
example,  there  are  two  primitive  functions  on  dotted  pairs.  Car  and  Cdr,  with  functionalities  as  shown 
below.  (Datum  is  the  union  type  of  atoms,  dotted  pairs,  vectors  and  integers.) 

Cdr:  dotted-pair  -*  datum 
Car:  dotted-pair  -*  datum 

Note  that  the  Car  and  Cdr  functions  above  are  not  the  same  as  the  car  and  cdr  operations  of  the 
Lisp  programming  language,  but  are  the  vocabulary  in  terms  of  which  the  effect  of  these  and  the  other 
builtin  Lisp  operations  will  be  specified.  Due  to  the  presence  of  side  effects  in  Lisp,  it  is  important  to 
distinguish  carefully  between  the  notion  of  a  relationship  like  Car,  which  holds  between  two  objects  at  a 
given  point  in  time,  and  an  operation,  like  the  application  of  car,  which  has  an  input  and  an  output, 
which  are  in  the  Car  relation  to  each  other. 

The  final  step  in  translating  from  Lisp  to  surface  plans  is  to  translate  the  primitives  operations  such 
as  car,  cor,  cons,  rplaca  and  rplaco,  into  input-output  specifications  in  terms  of  the  primitive  relations, 
such  as  Car  and  Cdr.  For  example,  cons  becomes  a  input-output  specification  which  takes  as  input  two 
data  objects,  and  returns  as  output  a  dotted  pair  whose  Car  and  Cdr  arc  the  first  and  second  inputs, 
respectively,  rplaca  and  rplaco  become  input-output  specification  which  modify  the  Car  and  Cdr 
functions  (i.e.  specializations  of  Newarg). 


1.  This  has  been  implemented  for  Lisp  by  Waters  [74]. 

2.  This  is  the  mathematical  notion  of  an  integer.  The  distinction  between  this  and  the  fixed  width  computer  representation  of  an 
integer  in  lisp  is  not  made  here,  because  there  arc  no  plans  in  the  current  library  which  require  this  distinction. 
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Two  additional  primitive  relations  in  Lisp  arc  Null  and  Eq,  with  functionalities  as  shown  below. 

Null:  datum  -*  boolean 
Eq:  datum  X  datum  -*  boolean 

Similarly,  the  distinction  is  made  between  a  relation  and  a  computation  which  tests  whether  that  relation 
holds  for  a  given  tuple  of  objects.  For  example,  code  such  as  the  following  constructions  with  cohd  is 
translated  into  the  plan  calculus  as  test  specifications  (specializations  of  ©Predicate)  involving  Null  and 
Eq,  respectively. 

(COHO  ((HULL  ...)  ...)) 

(COHO  ((EQ  ...)  ...)) 

Two  more  primitive  functions  used  to  model  Lisp  in  the  plan  calculus  are  the  following  functions 
on  Lisp  vectors  (one  dimensional  arrays). 

Dim:  vector  -*  integer 
Element:  vector  X  integer  -*•  datum 

The  primitive  vector  creation  (array)  and  accessing  (arrayfetch  and  arraystore)  actions  of  Lisp  are 
specified  in  surface  plans  in  terms  of  these  functions. 

4.4  Overlays 

An  overlay  is  essentially  a  triple  consisting  of  two  plans  and  a  set  of  correspondences  between  roles 
of  the  two  plans.  An  overlay  can  also  be  thought  formally  as  a  mapping  from  the  set  of  computations  (or 
data  structures)  specified  by  one  plan  to  the  set  specified  by  the  other.  For  example,  the  following 
overlay,1 

Composcd>function:  composed-functions  -*■  function 

is  a  mapping  from  instances  of  Composed-functions  to  instances  of  Function.  Composed-functions  is  a 
data  plan  whose  two  roles,  named  One  and  Two,  arc  functions  with  the  constraint  that  the  range  of 
function  One  is  a  subset  of  the  domain  of  function  Two.  Given  an  instance  of  Composed- functions,  the 
definition  of  Composed>function  (which  is  written  out  formally  in  the  appendix)  specifies  how  to  view  it 
as  the  implementation  of  a  single  function  from  the  domain  of  function  One  to  the  range  of  function 
Two.  This  overlay  is  a  many-to-one  mapping,  since  there  are  many  ways  a  given  function  may  be 
implemented  as  the  composition  of  two  functions.  Other  overlays,  such  as  between  List  and  Sequence, 
arc  one-to-one,  which  amounts  to  an  isomorphism  between  the  two  sets  of  instances. 

An  important  property  of  overlays  is  that  an  overlay  and  its  inverse  mapping  must  both  be  total  on 
the  specified  domain  and  range.  This  means  that,  given  any  instance  of  the  domain  type,  there  exists  a 
corresponding  instance  of  the  range  type.  For  example,  using  the  overlay  Composed)  function  in 
program  analysis,  if  we  recognize  an  instance  of  Composed-functions,  it  is  important  to  know  that  there 


1.  The  character  ">"  is  intended  to  be  read  as  "as". 
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exists  a  corresponding  instance  of  Function  which  it  implements.  Conversely,  for  program  synthesis  it  is 
important  to  know  that  for  every  instance  of  the  range  type  of  an  overlay,  there  exists  an  instance  of  the 
domain  type  which  is  a  valid  implementation  of  it. 

Fig.  4-6  shows  the  kind  of  diagram  which  is  used  to  represent  an  overlay  between  two  temporal 
plans.  This  overlay  expresses  how  to  view  the  composed  application  of  two  compatible  functions  as  the 
application  of  a  composed  function.  An  overlay  di.  _  am  is  divided  in  half  by  a  line  down  the  middle. 
The  left  side  shows  the  plan  diagram  for  the  domain  of  the  overlay;  the  right  hand  side  shows  the  plan 
diagram  for  the  range.  Correspondences  are  drawn  as  lines  with  hooks  on  the  ends  which  connect  roles 
on  one  side  with  roles  on  the  other. 

The  domain  of  the  overlay  in  Fig.  4-6  is  Composed-@functions,  which  has  three  roles:  One  and  Two 
are  instances  of  ©Function,  and  Composite  is  an  instance  of  Composed-functions.  Data  flow  constraints 
in  the  Composed-@functions  plan  are  such  that  the  functions  Composite.One  and  Composite.Two 
become  the  inputs  One.Op  and  Two.Op,  respectively;  and  One.Output  becomes  Two.Input  The  range 
of  the  overlay  is  @Function. 

Correspondences  in  overlay  diagrams  are  both  labelled  and  unlabclled.  Unlabelled 
correspondences  denote  equality  between  the  indicated  roles.  Labelled  correspondences  indicate  equality 
between  the  value  of  labelling  function  applied  to  the  role  on  the  left  and  the  role  on  the  right  The 
function  involved  in  such  correspondences  is  most  often  another  overlay. 

For  example,  there  arc  three  correspondences  in  Fig.  4-6.  The  topmost  correspondence  says  that 
the  Composite  role  of  Composcd-@functions  on  the  left  hand  side  (an  instance  of  Composed-functions), 
viewed  as  a  function  according  to  the  overlay  Composed > function,  is  equal  to  the  Op  role  of  ©Function 
on  the  right.  Note  that  the  overlay  Composed>  function,  defined  earlier,  is  being  used  here  to  define  a 
larger  overlay  which  includes  composed  functions.  This  will  occur  twice  more  later  in  this  section. 

The  otheT  two  correspondences  in  Fig.  4-6  are  simple  equalities.  The  first  correspondence  means 
that  for  an  instance  of  Composed-@functions  and  an  instance  of  ©Function  related  as  Composed) 
©function,  Composcd-@functions.One.Input  is  equal  to  the  object  filling  ©Function.lnput.  Similarly 
Composed-@fiinctions.Two.Output  is  equal  to  @Function.Output 

The  reader  may  note  that  in  die  formal  definition  of  Composed>@Function  in  the  appendix  there 
are  two  more  correspondences  which  are  not  shown  in  Fig.  4-6:  the  input  situation  of  Composed- 
©functions.One  is  identified  with  the  input  situation  of  ©Function;  and  the  output  situation  of 
Composed-@functions.Two  is  identified  with  the  output  situation  of  ©Function.  To  reduce  clutter,  such 
correspondences  between  input  and  output  situations  will  usually  omitted  in  overlay  diagrams  when  they 
can  be  naturally  inferred. 

Fig.  4-7  shows  another  overlay  involving  composed  functions.  This  overlay,  Newvaluc- 
composite>ncwvaluc,  expresses  the  idea  that,  given  a  function  implemented  as  a  composition,  a  Newvalue 
operation  on  component  Two  of  the  composition  can  be  viewed  as  a  Newvalue  operation  on  the  whole 
function.  This  overlay  is  used  in  the  analysis  of  the  symbol  table  add  and  delete  programs  of  Chapter 
Two.  The  hash  table  in  those  programs  is  viewed  as  a  function  implemented  as  the  composition  of  two 
functions;  a  numerical  hash  function  which  doesn’t  change,  and  a  sequence  (implemented  as  an  array), 
which  is  modified  to  insert  new  entries. 
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Figure  4*6.  Applying  a  Functional  Composition. 
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Notice  the  equality  constraint  between  Old.One  and  New.One  on  the  left  hand  side  in  Fig.  4-7. 
This  style  of  building  up  larger  plans  by  making  use  of  instances  of  already  defined  plans  and 
constraining  certain  components  to  correspond,  allows  us  to  be  very  concise.  More  important,  we  have 
separated  what  is  novel  about  a  particular  plan,  like  Newvalue-compositc,  from  what  it  has  in  common 
with  other  plans.  Similarly  notice  that  the  Newvaluc-compositoncwvalue  overlay  makes  use  of  the 
Composed>  function  overlay  twice  in  its  definition. 

A  Familiar  Example 

This  section  presents  a  second  introductory  example  of  overlays:  the  implementation  of  lists  using 
an  array  and  an  index.  This  particular  implementation  is  included  here  because  it  is  a  familiar  example 
from  many  other  papers  on  representing  programming  knowledge. 

We  begin  with  the  idea  of  viewing  a  segment  of  a  sequence  between  two  bounds  as  a  sequence.1 
This  is  formalized  by  the  overlay  Scgment>sequcnce,  which  says  (see  appendix)  that  the  terms  of  the 
implemented  sequence  correspond  to  the  terms  of  the  base  sequence,  offset  by  the  lower  bound.2 

A  specialization  of  Segment  is  Upper-segment,  in  which  the  upper  bound  is  equal  to  the  length  of 
the  base  sequence.  Upper-segment  is  a  data  plan  often  used  to  implement  a  list.  The  head  of  the 
implemented  list  corresponds  to  the  term  of  the  base  sequence  indexed  by  the  lower  bound,  and  the  tail 
of  the  list  is  recursively  defined  as  the  list  implemented  by  the  upper  segment  which  has  the  same  base 
sequence  with  one  plus  the  lower  bound.  The  empty  list  (Nil)  is  implemented  by  a  segment  in  which  the 
lower  bound  meets  the  upper  bound,  i.e.  when  the  lower  bound  is  equal  to  the  length  of  the  sequence. 
This  implementation  is  specified  formally  by  the  overlay  Upper-scgmcnt>list  in  the  appendix. 

Fig.  4-8  defines  the  overlay  Rump+update>push,  which  shows  how  to  implement  a  Push  operation 
on  a  list  implemented  as  described  above.  The  plan  on  the  left  hand  side,  Bump+updale,  has  four  roles: 
Bump,  an  instance  of  @Oneminus  (the  specialization  of  @Function  when  the  Op  is  Oncminus);  Update, 
an  instance  of  Newterm;  and  Old  and  New,  instances  of  Upper-segment.  The  essence  of  this  plan  is  . 
update  the  term  of  the  base  sequence  at  one  minus  the  lower  bound.  The  correspondences  in  the  overlay 
specify  how  this  plan  can  be  viewed  as  a  Push  operation  by  viewing  Updatc.Old  together  with  the 
Bump.lnput  as  the  Old  input  of  Push  (implemented  according  to  Uppcr-scgmcnt>list),  viewing 
Updatc.Input  as  the  Input  of  Push,  and  viewing  Update.New  together  with  the  Bump.Output  as  the  New 
output  of  Push  (again,  according  to  Upper-segment>list). 

Similarly,  Fig.  4-9  defines  the  overlay  Fetch+Updatopop,  which  specifies  how  to  implement  a  Pop 
operation  on  a  list  implemented  by  Upper-segment>lisu  Here  we  see  that  the  base  sequences  of  the  old 
and  new  upper  segments  are  the  same.  One  is  added  to  the  lower  bound.  The  Output  of  Fetch 
corresponds  to  the  Output  of  Pop.  The  Fetch  and  Bump  operations  may  occur  in  any  order  since  neither 
uses  the  output  of  the  other. 


1.  We  arc  skipping  the  step  of  modelling  an  array  as  a  sequence,  which  is  part  of  the  surface  plan  translation. 

2.  This  implementation  "wastes'’  the  first  and  and  last  terms  of  the  hasc  sequence.  It  can  be  improved  by  adding  Oncplus  and 
Oneminus  in  various  places,  but  this  would  just  make  the  example  more  complicated  without  adding  any  new  ideas. 
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Figure  4*8.  Implementation  of  Push. 
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Figure  4-9.  Implementation  of  Pop. 
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Using  Overlays 

We  will  see  many  more  examples  of  overlays  in  this  and  the  following  chapters.  In  Chapters  Five 
and  Six  we  will  also  see  how  overlays  arc  used  in  analysis  and  synthesis.  For  now  just  a  few  general 
introductory  remarks  are  in  order. 

We  have  already  seen  that  overlays  are  tool  for  codifying  programming  knowledge.  An  overlay  can 
encapsulate  a  chunk  of  implementation  knowledge  so  that  it  may  be  used  many  times  in  building  up 
larger  chunks.  Such  overlays  express  a  generalization  of  many  specific  implementation  strategies. 

In  analysis  and  synthesis  scenarios,  overlays  are  invoked  by  pattern  matching  against  one  side,  of  the 
overlay  and  instantiating  the  other.  For  example,  suppose  we  are  in  the  midst  of  synthesizing  a  program 
and  at  some  point  we  nave  a  plan  involving  an  instance  of  Push.  One  thing  wc  could  do  is  search  the  plan 
library  for  an  overlay  which  has  Push  on  the  right  hand  side,  for  example  Bump+update>push,  and 
instantiate  the  left  hand  side,  in  this  case  Uump+update.  The  are  many  questions  unanswered  here 
concerning  how  the  search  and  matching  is  performed  and  how  the  instantiated  plan  is  hooked  up  with 
the  existing  plan  structure.  Some  of  these  will  be  dealt  with  in  Chapter  Five. 

In  bottom-up  analysis,  overlays  are  used  in  a  similar  way  to  build  up  more  abstract  descriptions  of 
the  program  under  analysis.  The  first  step  is  to  recognize  known  plans  in  the  surface  plan  translation  of 
the  program.  This  may  involve  deduction,  since  some  of  the  required  constraints  may  not  yet  be  explicit 
assertions.  Furthermore,  this  recognition  process  can  be  made  more  hypothesis  driven  by  first  matching 
against  explicit  assertions  and  then  either  trying  to  derive  the  rest  of  the  required  constraints,  or  assuming 
them  in  order  to  accumulate  more  evidence  for  and  against  the  hypothetical  analysis.  Once  a  plan  has 
been  recognized,  we  seek  to  overlay  it  with  another  equivalent  or  more  abstract  plan.  This  is  achieved  by 
searching  the  library  as  above  for  overlays  which  have  the  given  plan  on  the  left  hand  side.  Having  found 
one,  an  instance  of  the  plan  on  right  hand  side  is  made  and  add  to  the  analysis. 

Finally,  overlays  can  be  used  in  verification.  Whether  we  arc  analyzing  an  existing  program  or  have 
started  with  initial  specifications  for  a  new  program  to  be  synthesized,  the  final,  fully  verified  description 
is  a  decomposition  of  the  program  into  plans  and  sub-plans  connected  by  overlays.  From  this  standpoint, 
overlays  are  pre-verified  lemmas  in  the  verification  of  a  program.  Some  overlays  may  be  quite  difficult  to 
verify  from  first  principles.  However,  once  this  has  been  done,  they  can  be  used  over  and  over  again. 
One  of  the  goals  of  the  library  is  to  compile  enough  of  these  pre-verified  overlays  so  that  the  verification 
of  routine1  programs  becomes  mostly  a  matter  of  combining  these  pieces  with  very  little  difficult 
deduction  remaining. 


1.  There  is  an  intended  circularity  here.  I  propose  that  what  makes  certain  programs  "routine"  is  that  they  are  a  straightforward 
combination  of  familiar  chunks. 


/ 
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CHAPTER  FIVE 

ANALYSIS  BY  INSPECTION 


This  chapter  presents  a  detailed  scenario  of  the  automated  analysis  of  a  program  similar  to  part  o 
the  symbol  table  example  of  Chapter  Two.  The  input  to  this  analysis  is  the  Lisp  code  and  comment 
shown  in  Table  5-A.  The  output  of  this  analysis  is  a  hierarchy  of  plans  which  describe  the  computation 
performed  by  the  given  program  at  various  levels  of  abstraction.  The  topmost  plans  in  this  hierarch; 
describe  these  computations  in  very  abstract  terms,  i.c.  in  terms  of  set  operations.  The  bottommost  plan 
are  very  close  to  the  code.  They  describe  the  computations  in  terms  of  the  primitive  data  structures  am 
operations  of  Lisp,  such  as  dotted  pairs,  car  and  cdr.  Connections  between  these  different  levels  o 
description  are  represented  using  overlays. 

The  type  of  analysis  shown  in  this  chapter  can  be  construed  as  a  reconstruction  of  the  top-dowi 
design  of  a  program.  This  does  not  mean  that  the  given  program  was  actually  designed  that  way,  or  tha 
programs  should  be  designed  top-down.  It  only  means  that  a  top-down  account  is  a  useful  way  o 
understanding  an  existing  program. 

5.1  Why  Analysis? 

In  a  programmer’s  apprentice  system,  a  complete  reconstruction  of  the  abstract  structure  of 
program  as  illustrated  in  this  chapter  would  seldom  be  required,  since  the  intermediate  levels  o 
description  would  be  built  up  incrementally  as  part  of  the  development  process.  There  are,  howevei 
other  reasons  for  studying  this  type  of  analysis.  As  a  practical  matter,  automated  analysis  will  be  useful  it 


Table  5-A.  Lisp  Code  to  be  Analyzed. 


;  A  SET  OF  ENTRIES  IS  IMPLEMENTED  AS 
;  A  HASH  TABLE  ON  KEYS. 

;  THE  BUCKETS  ARE  IMPLEMENTED  AS  LISTS. 

(SETQ  TBL  (ARRAY  TBLSIZE)) 

(DEFINE  LOOKUP 
(LAMBDA  (KEY) 

(PROG  (BKT  ENTRY) 

(SETQ  BKT  (ARRAYFETCH  TBL  (HASH  KEY))) 
LP  (COND  ((NULL  BKT)(RETURN  NIL))) 

(SETQ  ENTRY  (CAR  BKT)) 

(COND  ((EQ  (CAR  ENTRY)  KEY) 

(RETURN  ENTRY))) 

(SETQ  BKT  (CDR  BKT)) 

(GO  LP)))) 


(DEFINE  HASH 
(LAMBDA  (KEY) 

(REMAINDER  (MAKNUM  KEY)  TBLSIZE))) 
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convening  from  present  programming  technology,  which  deals  primarily  with  code,  to  future 
technologies  which  will  involve  many  levels  of  description.  Furthermore,  for  the  foreseeable  future  the 
common  medium  for  transfer  of  programs  between  different  systems  is  likely  to  be  code  written  in  a 
standard  programming  language.  For  both  of  these  purposes,  it  is  necessary  to  be  able  to  reconstruct  a 
plausible  design  from  given  code,  systems. 

More  fundamentally,  many  of  the  capabilities  required  for  program  analysis  are  important  in  other 
parts  of  the  programming  process  as  well.  For  example,  the  ability  to  recognize  standard  computations 
(analysis  by  inspection)  at  various  levels  of  abstraction  is  important  for  automating  both  synthesis  and 
verification,  even  in  an  incremental  system.  This  is  because  there  are  often  several  different,  but  equally 
intuitive,  ways  of  abstracting  a  given  computation.  For  example,  the  symbol  table  lookup  procedure  can 
be  abstracted  either  as  associative  retrieval  (i.e.  finding  an  entry  in  a  set  satisfying  a  given  predicate),  or  as 
the  application  of  a  (partial)  function  from  keys  to  entries.  A  programmer  may  be  developing  a  program 
along  one  of  these  viewpoints,  but  the  system  may  have  to  reanalyze  it  in  a  different  way  in  order  to  bring 
the  power  of  the  plan  library  to  bear.  Furthermore,  in  an  interactive  program  development  system,  this 
reanalysis  need  not  wait  until  the  plans  involved  are  specific  enough  to  be  translated  into  code  — 
reanalysis  can  be  useful  at  all  levels  of  abstraction. 

5.2  Overview 

The  overall  goal  of  the  analysis  described  in  this  chapter  is  to  decompose  a  given  program  into  parts 
which  are  recognized  from  the  plan  library'.  This  is  done  in  four  major  steps.  The  first  two  steps  are 
basically  algorithmic  and  have  been  implemented.  The  second  two  steps  are  of  a  more  heuristic  nature, 
and  have  not  yet  been  implemented.  In  summary,  while  this  chapter  gives  a  fairly  complete  account  of 
what  constitutes  the  analysis  of  a  program,  it  only  goes  part  way  towards  automating  the  process  of 
constructing  one. 

The  first  step  in  analyzing  an  already  written  program  is  to  translate  from  the  given  program 
programming  language  into  the  plan  calculus.  This  step  is  viewed  as  a  translation  because  it  does  not 
involve  any  programming  knowledge  other  than  the  semantics  of  the  programming  language.  The  plans 
which  are  are  the  output  of  this  translation  step  are  called  surface  plans.  The  purpose  of  this  translation 
step  is  to  insulate  the  rest  of  the  analysis  process  from  the  syntactic  differences  between  various 
programming  languages.  Surface  plans  resulting  from  the  translation  of  Lisp  code  were  described  briefly 
in  Chapter  Four.  Code  to  surface  plan  translation  has  also  been  implemented  for  Fortran  (73]  and 
Cobol  (24). 

The  second  step  of  analysis  described  in  this  chapter  is  loop  analysis.  The  purpose  of  this  step  is  to 
decompose  loops  and  recursions  in  a  way  which  makes  producer-consumer  relationships  explicit 
Furthermore,  the  producer  and  consumer  components  resulting  from  this  decomposition  are  often 
specializations  of  standard  plans  in  the  library.  For  example,  temporal  analysis  decomposes  the  loop  in 
lookup  roughly  into  three  parts:  cor  generation,  iterative  application  of  car,  and  iterative  testing  for  an 
entry  with  the  given  key.  These  components  arc  connected  by  data  streams  which  represent  the  history  of 
values  taken  on  by  the  loop  variables  bkt  and  entry.  The  idea  for  this  type  of  loop  analysis  using  the  plan 
calculus  was  developed  and  has  been  implemented  by  Waters. 
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The  final  two  steps  of  analysis  in  this  chapter  are  less  well  worked  out.  T  he  basic  idea  is  to  try  to 
recognize  known  plans,  first  working  bottom-up  and  then  top-down.  Working  bottom-up  entails 
regrouping  parts  of  the  surface  plan  and  the  temporal  analysis  so  as  to  match  plans  in  the  library.  One 
method  of  controlling  this  process  is  to  use  the  types  of  the  various  descriptions  involved  (such  as  list, 
number,  test,  or  loop)  as  a  first  filter  on  the  grouping  and  matching.  Also,  not  all  plans  in  the  library  are 
considered  in  this  first  bottom-up  matching  phase.  For  example,  with  the  current  library,  bottom-up 
analysis  goes  as  far  as  recognizing  plans  which  have  distinctive  control  flow  and  data  flow  features,  but 
docs  not  include  recognizing  program  structure  having  to  do  with  the  hash  table.  How  far  bottom-up 
methods  can  proceed  with  a  larger  plan  library  is  an  issue  for  further  study. 

The  final  step  of  plan  recognition  in  this  chapter  is  top-down  analysis  by  synthesis.  I  assume  that 
we  are  given  a  high  level  description  of  the  program  to  start  with.  For  example,  for  the  symbol  table 
program  we  are  told  that  "a  set  of  entries  is  implemented  as  a  hash  table  on  keys",  and  that  "the  buckets 
are  implemented  as  lists".  The  concepts  of  set,  hash  table,  key,  bucket  and  list  are  all  known  in  the 
current  library.  Furthermore,  the  names  of  the  Lisp  functions  in  Table  5-A,  hash  and  lookup,  and  the 
names  of  their  arguments,  key  and  entry,  are  taken  as  part  of  the  program  documentation  indicating  that 
these  procedures  implement  a  hashing  function  and  associative  retrieval  from  the  set  of  entries, 
respectively. 

The  basic  idea  of  analysis  by  synthesis  is  to  use  the  plan  library  to  generate  possible 
implementations  of  the  given  high  high  level  description  until  we  find  one  which  matches  the  existing 
bottom-up  analysis.  With  the  current  library  and  the  symbol  table  example,  this  technique  appears  to  be 
feasible  with  simple  breadth-first  search  through  the  space  of  possible  implementations.  With  a  larger 
library,  some  additional  control  mechanisms  will  need  to  be  developed.  Fickas  [25]  has  done  some  initial 
work  in  this  direction. 

The  approach  of  dividing  plan  recognition  into  a  bottom-up  phase  and  a  top-down  phase  has  the 
feature  that  programs  for  which  the  appropriate  higher  level  plans  are  not  in  the  library  can  still  be 
partially  analyzed  at  the  lower  levels.  For  example,  if  the  methods  described  in  this  chapter,  together  with 
the  current  plan  library,  were  applied  to  analyzing  an  associative  retrieval  data  base  implemented  entirely 
with  linked  lists,  the  top-down  part  of  recognition  would  fail,  but  we  would  still  succeed  in  analyzing  the 
structure  of  the  program  at  the  level  of  search  loops  and  list  manipulations. 

The  next  four  sections  illustrate  the  four  steps  of  analysis  outlined  above  using  lookup.  Note  that 
there  is  not  much  to  say  about  the  analysis  of  the  first  two  s-expressions  in  Table  5-A  by  themselves. 
These  expressions  simply  create  a  Lisp  vector  (tbl)  of  a  specified  size  and  define  a  numerical  function 
(hash),  both  of  which  arc  used  later. 

5.3  Surface  Plans 

This  section  discusses  the  surface  plan  of  lookup  in  detail,  explaining  both  the  specifics  of  this 
example,  and  some  points  about  surface  plans  in  general. 

The  surface  plan  of  lookup  is  shown  in  Fig.  5-1  and  Fig.  5-2.  At  the  top  level,  this  plan  has  three 
steps:  application  of  the  hashing  function,  fetching  from  the  hash  table,  and  a  loop  with  two  exits.  This 
structure  is  shown  in  Fig.  5-1  as  the  plan  named  Lookup-surface  with  four  roles  named  One,  Two,  Loop 
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and  End.  (The  fourth  role.  End,  is  required  to  join  the  two  cases  of  the  loop).  The  Loop  role  of  Lookup- 
surface  is  further  described  by  another  plan.  Lookup-loop,  which  is  shown  partially  in  Fig.  5-1,  and  in  full 
in  Fig.  5-2.  The  names  of  these  plans  and  their  roles  are  generated  by  the  translation  process  based  on 
some  simple  conventions. 

Note  in  these  figures  that  inputs  and  outputs  that  are  not  constrained  by  data  flow  arc  usually  either 
unconstrained  (as  far  as  the  larger  plan  is  concerned)  or  fixed  to  some  constant.  Unconstrained  inputs 
and  outputs  are  labelled  with  the  appropriate  role  names  in  ovals.  Roles  that  are  fixed  to  constants  are 
indicated  by  writing  the  constant  inside  the  corresponding  oval.  Constants  can  be  distinguished  from  role 
names  by  the  absence  of  the  point  prefix.  All  of  these  notations  are  illustrated  by  Lookup-surface.One  in 
Fig.  5-1.  The  function  being  applied  (Lookup-surface.Onc.Op)  is  a  constant,  Hashl,  which  is  the 
numerical  function  defined  by  hash.  The  argument  to  the  function  (Lookup-surface.One.lnput),  which 
corresponds  to  the  variable  key  in  the  code,  is  unconstrained.  Finally,  there  is  a  data  flow  link  between 
Lookup-surface.Onc.Output  and  the  second  input  of  Two. 

The  input-output  specification  of  Lookup-surface.One  is  @Function,  the  application  of  a  given 
function  (Op)  to  a  given  domain  element  (Input)  to  compute  the  corresponding  range  element  (Output). 
In  the  case  of  Lookup-surface.One,  the  function  applied  is  Hashl. 

The  input-output  specification  of  Lookup-surface.Two  is  Fetch.  The  inputs  to  a  Fetch  operation 
are,  in  order  from  left  to  right,  Input  (a  Lisp  vector)  and  Index  (a  valid  numerical  index  for  that  vector). 
The  Output  is  the  indexed  clement  of  the  input  vector.  Lookup-surface.Two.Input  is  constrained  to  be 
Vectorl,  the  Lisp  vector  created  in  tbl. 

After  Lookup-surface.Two,  control  flows  into  Lookup-surface.I^op.  As  can  be  seen  in  Fig.  5-1, 
control  exits  from  the  loop  at  two  different  locations.  These  two  exits  correspond  to  the  two  return 
statements  in  the  code  for  lookup.  In  one  case,  (return  entry)  there  is  also  data  flow  out  of  the  loop. 

The  surface  plan  for  the  looping  part  of  LOOKUP  is  shown  in  full  in  Fig.  5-2.  The  most  prominent 
feature  of  this  plan  is  that  it  is  recursively  defined.  In  the  plan  calculus,  loops  are  represented  using 
recursive  definition,  as  suggested  by  the  following  code. 

(DEFINE  LOOKUP 
(LAMBDA  (KEY) 

(PROG  (BKT  ENTRY) 

(SETQ  BKT  (ARRAYFETCH  TBL  (HASH  KEY))) 

(LP)))) 

(DEFINE 

(LAMBDA  () 

(COND  ((NULL  BKT) (RETURN  NIL))) 

(SETQ  ENTRY  (CAR  BKT)) 

(COND  ((EQ  (CAR  ENTRY)  KEY) 

(RETURN  ENTRY))) 

(SETQ  BKT  (CDR  BKT)) 

(!£)))) 

This  turns  out  to  be  the  most  convenient  representation  for  many  purposes,  especially  for  making 
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inductive  arguments  in  program  verification.1  In  plan  diagrams,  recursive  definition  is  indicated  by  a 
curly  line,  as  in  the  lower  left  of  Fig.  5-2.  This  notation  means  that  the  Tail  role  of  Lookup-loop  is 
defined  to  have  the  same  plan  as  Lookup-loop.  Enough  of  the  Tail  is  expanded  in  this  diagram  to  specify 
the  connections  between  one  repetition  of  the  loop  and  the  next 

Lookup-loop  has  seven  other  roles,  in  addition  to  Tail.  Three  of  these  (One,  Two  and  Three)2  are 
applications  of  the  primitive  Lisp  functions.  Car  and  Cdr.  These  are  the  translations  of  (car  bkt), 
(car  entry)  and  (cdr  bkt)  in  the  code.  The  other  four  roles  in  Lookup-loop  are  various  kinds  of  tests 
and  joins. 

Two  particular  kinds  of  test  specifications  used  in  Lookup-loop  are  ©Predicate  and’  ©BinreL 
©Predicate  tests  whether  or  not  a  given  unary  relation  (Criterion)  is  true  of  given  object  Similarly, 
@Binrd  tests  whether  two  given  objects  satisfy  a  given  binary  relation  (Criterion). 

The  first  test  in  Lookup-loop,  If-one,  is  constrained  to  be  a  instance  of  @ Predicate  in  which  the 
Criterion  is  Null.  If-one  is  the  translation  of  the  code 

(COND  ((NULL  BKT)...))  . 

When  this  test  succeeds,  control  exits  from  the  loop,  as  can  be  seen  by  the  control  flow  arrow  from 
the  "S"  side  of  If-onc  which  bypasses  the  Tail.  When  this  test  fails,  control  passes  to  One  and  then  Two, 
which  are  the  translation  of  the  following  portion  of  the  loop  code. 

(SETQ  ENTRY  (CAR  BKT)) 

...(CAR  ENTRY)... 

The  output  of  Two  feeds  into  input  One  of  If-two,  which  is  an  instance  of  ©Binrel.  The  Criterion 
of  this  test  is  the  primitive  binary  relation,  Eq.  If-two  is  the  translation  of  the  code 

(COND  ((EQ  ...  KEY)  ...))  . 

Note  that  If-two.Two  (key  in  the  code  above)  is  unconstrained  as  far  as  the  Lookup-loop  plan  is 
concerned,  except  that  it  doesn’t  change  on  successive  repetitions  of  the  loop.  The  fact  that  input  Two  of 
this  test  is  the  same  as  the  argument  to  the  hashing  function  is  reflected  in  the  constraints  of  Lookup- 
surface,  as  can  be  seen  in  Fig.  5-1.  If  this  test  succeeds,  control  exits  the  loop  through  End-two  making 
One.Output  (entry)  available  outside  the  loop.  Otherwise,  Cdr  is  applied  to  If-one.Input  (bkt),  with  the 
result  feeding  into  the  recursive  invocation. 

Lookup-surface.End,  Lookup-loop.End-one  and  Lookup-loop.End-two  are  joins,  the 
complementary  construct  to  tests.  There  are  two  possible  ways  for  control  to  flow  into  a  join,  and  one 
way  out.3  Joins  indicate  the  effect  of  control  flow  on  data  flow.  For  example,  the  pattern  of  data  flow 
and  control  flow  through  Lookup-surface.F.nd  in  Fig.  5-1  indicates  that  in  one  case  the  value  returned  by 


1.  Many  lisp  interpreters  and  compilers  execute  tail  recursive  code  as  efficiently  as  code  with  loops  in  control  (low.  making  these 
essentially  syntactic  variants. 

1  As  in  Lookup-surrace,  the  role  names  in  this  plan  are  chosen  by  the  translation  process  based  on  some  simple  conventions. 

3.  Note  that  this  is  not  a  parallelism  construct  In  any  given  compulation,  only  one  or  the  other  branch  of  a  conditional  is  taken. 
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lookup  is  the  entry  that  satisfied  the  second  exit  test  of  the  loop  (the  value  of  entry);  in  the  other  case  it  is 
the  constant.  Nil. 

5.4  Loop  Analysis 

The  overall  goal  of  analysis  by  inspection  is  to  decompose  a  program  into  recognizable  parts.  In 
other  words,  we  want  to  figure  out  how  the  surface  plan  for  a  program  could  be  built  up  out  of  standard 
plans  in  the  library.  This  section  in  particular  is  concerned  with  the  analysis  of  singly  recursive  surface 
plans,  such  as  Lookup-loop,  which  represent  the  looping  parts  of  a  program.  It  is  important  to  note, 
however,  that  none  of  the  analysis  in  this  section  is  particular  to  whether  a  surface  plan  is  the  translation 
of  code  written  in  Lisp  versus  some  other  conventional  programming  language.  Although  appropriate 
specializations  for  Lisp  will  be  emphasized  for  the  purpose  of  this  example,  the  plans  and  overlays 
introduced  in  this  section  are  all  quite  general. 

The  analysis  of  loops  takes  place  in  two  steps.  In  the  first  step,  a  loop  is  decomposed  into  standard 
recursively  defined  fragments.  In  the  second  step,  the  behavior  of  these  fragments  is  abstracted  in  such  a 
way  that  a  loop  can  be  represented  by  a  non-recursive  plan.  This  allows  further  analysis  to  treat  the 
looping  and  non-looping  parts  of  programs  uniformly. 

Loop  Augmentations 

The  natural  building  blocks  for  non-recursive  temporal  plans  are  input-output  and  test 
specifications,  which  arc  composed  using  control  flow  and  data  flow.  The  plan  library  contains  many 
standard  input-output  and  test  specifications  and  plans  for  their  implementation  by  compositions  of  other 
input-output  and  test  specifications.  For  recursively  defined  temporal  plans,  however,  a  different  notion 
of  composition  is  needed  in  order  to  make  a  library  of  standard  building  blocks.  Loops  are  viewed  here 
as  being  constructed  by  a  process  of  augmentation }  For  example,  the  loop  of  lookup  can  be  constructed 
starting  with  just  the  part  that  does  the  coRing,  as  suggested  by  the  following  code. 

(PROG  (BKT) 

(SETQ  BKT  ...) 

LP  ... 

(SETQ  BKT  (COR  BKT)) 

(GO  LP)) 

This  pattern  of  looping,  in  which  a  given  function  is  repeatedly  applied  to  the  output  of  the 
preceding  application  of  that  function,  is  called  Iterative-generation.  Iterative-generation  using  Cdr  is  a 
common  building  block  of  many  loops  in  Lisp.  This  loop  can  be  augmented  by  adding  the  code 
underlined  below. 


1.  This  view  of  loops  is  taken  from  Waters  [73],  In  this  reference.  Waters  also  goes  into  a  more  lengthy  jusUfication  of  why  a 
different  analysis  method  is  required  for  loops  as  compared  to  straight-line  code. 
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(PROG  (BKT  ENTRY ) 

(SETQ  BKT  ...) 

LP  ... 

(SETO  ENTRY  (CAR  BKTt  t 

(SETQ  BKT  (CDR  BKT)) 
(GO  LP)) 


The  basic  idea  of  augmentation  is  that  the  augmented  loop  does  everything  the  unaugmented  loop 
does,  plus  something  extra.  For  example,  the  augmented  loop  above  makes  available  in  entry  the  car  of 
each  successive  value  of  bkt  computed  by  the  generation  part  of  the  loop.  This  pattern  of  augmentation 
is  called  Iterative-application;  the  function  being  applied  in  this  case  is  Car.  In  general,  the  effect  of  an 
augmentation  is  to  create  a  new  sequence  of  data  objects  (such  as  the  values  of  entry)  in  the  augmented 
loop  which  is  related  in  some  way  to  a  sequence  of  objects  (such  as  the  values  of  bkt)  in  the  unaugmented 
loop.  Two  other  kinds  of  augmentation,  which  are  not  illustrated  in  the  symbol  table  example,  are 
filtering  and  accumulation.  These  will  be  discussed  in  Chapter  Nine. 

The  addition  of  an  exit  test  to  a  loop,  as  shown  underlined  below,  is  a  kind  of  augmentation  which 
is  an  exception  to  the  general  rule  that  augmentation  preserves  the  complete  behavior  of  the 
unaugmented  loop,  since  without  the  exit  test,  the  loop  generates  infinite  sequences  of  data,  which  is  not 
the  case  with  the  exit  test  present 


(PROG  (BKT  ENTRY) 

(SETQ  BKT  ...) 

LP  (COHO  ((HULL  BKT  WRETURN  NILUT 
(SETQ  ENTRY  (CAR  BKT)) 

(SETQ  BKT  (COR  BKT)) 

(GO  LP)) 


This  kind  of  augmentation  is  called  Iterative-termination.  The  reason  an  exit  test  is  treated  as  a  kind 
of  augmentation,  even  though  it  changes  the  behavior  of  the  loop,  is  because  it  effect  is  abstracted  in  the 
same  way  as  other  augmentations.  Adding  Iterative-termination  creates  truncated  versions  of  the 
(potentially  infinite)  sequences  which  would  be  generated  by  the  loop  without  the  exit  test.  More  than 
one  iterative  termination  can  be  added  to  a  loop,  as  shown  underlined  below. 


(PROG  (BKT) 

(SETQ  BKT  ...) 

LP  (COND  ((NULL  BKT)(RETURN  NIL))) 
(SETQ  ENTRY  (CAR  BKT)) 

(COND  ((EO  (CAR  ENTRY!  KEY! 

(RETURN  ENTRY! t \ 

(SETQ  BKT  (CDR  BKT)) 

(GO  LP)) 


Waters  has  implemented  a  system  which  automatically  decomposes  loops  according  to  this  idea  of 
augmentation.  The  basic  algorithm  his  system  uses  is  to  iteratively  remove  parts  of  a  loop  which  do  not 
produce  data  objects  required  by  the  remaining  parts.  For  example,  for  the  loop  example  above  (which  is 
part  of  lookup),  the  effect  of  this  algorithm  is  to  undo  the  augmentation  steps  in  the  reverse  order  they 
were  introduced  above.  The  plan  library  contains  plans  for  many  standard  augmentations,  'ihc  rest  of 
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this  section  shows  some  of  these  which  are  used  in  lookup  and  how  they  are  represented  in  the  plan 
calculus. 

The  first  augmentation  recognized  in  the  lookup  loop  is  shown  in  Fig.  5-3.  On  the  left  hand  side  of 
this  figure  we  have  the  surface  plan  for  the  loop.  Lookup-surface.  On  the  right  hand  side  is  a  plan  from 
the  library  called  Terminated-iterative-search.  This  plan  captures  the  idea  of  a  search  loop  with  two  exits, 
without  specifying  how  the  sequence  of  objects  being  searched  is  produced.  Role  If-two  of  this  plan  is  a 
test  which  applies  a  given  criterion  (the  same  on  each  iteration)  to  the  current  input  (provided  by  the  rest 
of  the  loop).  When  this  test  succeeds,  the  current  input  is  made  available  outside  the  loop  (as  End- 
two.Output).  The  other  exit  test  (If-one)  is  for  terminating  the  loop  when  there  are  no  more  objects  in  the 
search  space. 

Note  that  the  role  names  of  a  plan  in  the  library,  such  as  Terminated-iterative-search,  are  fixed  at 
the  time  the  plan  is  catalogued.  In  general,  role  names  have  been  chosen  to  have  some  mnemonic  value 
relative  to  the  given  plan,  but  this  strategy  is  somewhat  restricted  by  the  fact  that  specialized  plans  inherit 
their  role  names  from  their  generalizations.  For  example,  the  most  general  plan  for  a  two  exit  loop,  of 
which  Terminated-iterative-search  is  a  specialization,  is  Cascade-iterativc-tcrmination.  At  the  level  of 
generality  of  Cascade-iterative-termination,  it  is  not  possible  to  give  any  better  names  to  the  two  exit  test 
roles  than  If-one  and  If-two. 

The  hooked  lines  between  the  left  and  right  hand  sides  of  Fig.  5-3  indicate  how  the  Terminated- 
iterative-search  plan  is  matched  against  Lookup-surface:  Lookup-loop.If-onc  corresponds  to  Terminated- 
itcrative-search.If-one;  Lookup-loop.If-two  corresponds  to  Terminatcd-iterative-search.lf-two;1  and  there 
is  a  correspondence  between  the  joins,  End-one  and  End-two.  The  fact  that  the  corresponding  roles  have 
the  same  names  in  this  example  is  a  coincidence.  The  hooked  line  between  Lookup-loop.Tail  and 
Terminated-itcrative-search.Tail  indicates  that  the  correspondence  is  made  recursively. 

Fig.  5-3  is  an  example  of  an  overlay.  The  basic  idea  of  overlays  is  re-description.  The  plan  on  the 
left  describes  a  set  of  computations  —  the  instances  of  the  plan.  The  correspondences  in  the  figure 
indicate  how  to  re-describe  (part  of)  any  such  computation  as  an  instance  of  the  plan  on  the  right,  in  this 
case  a  standard  plan  from  the  library.  In  order  for  this  re-description  to  be  possible,  the  constraints  of  the 
right  hand  plan  must  logically  follow  from  the  constraints  of  the  left  hand  plan,  substituting  appropriately 
for  the  corresponding  parts.  It  can  be  seen  in  Fig.  5-3  that  this  condition  is  met  for  control  flow  and  data 
flow  constraints  (control  flow  is  transitive). 

Overlays  are  used  to  relate  different  levels  of  description  in  the  analysis  o.'  r>rogram.  The  origin  of 
the  term  "overlay"  is  to  suggest  different  plans  being  drawn  on  transparent  slides  and  laying  one  on  top  of 
the  other  to  line  up  the  corresponding  parts.2  Some  overlays,  such  as  the  one  in  Fig.  5-3,  are  particular  to 


1.  A  detail  is  being  skipped  here,  which  is  covered  in  the  appendix.  Lookup-loop.If-two  is  an  instance  of  (ffBinrcl,  test  in  which 
the  binary  relation  Eq  is  applied  to  two  inputs.  Tcrminatcd-iterative-scarch.If-two  is  an  instance  of  ©Predicate,  a  lest  involving  a 
unary  relation.  In  order  to  recognize  Terminated-iterative-search  as  indicated,  an  intermediate  step  is  required  in  which 
Lookup- loop.lf-two  is  grouped  together  with  Lookup- loop. Two  and  these  arc  viewed  as  the  implementation  of  testing  a  composite 
predicate  of  the  form  (LAMBDA  (X)(EQ  (CAR  X)  KEY)). 

2.  Sussman  (69)  uses  the  term  "slice"  for  a  similar  concept  in  the  analysis  of  electronic  circuits. 
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the  analysis  of  a  specific  program;  others,  such  as  those  catalogued  in  the  plan  library,  express  re¬ 
descriptions  of  general  applicability. 

Recognition  of  the  other  augmentations  in  Lookup-loop  takes  place  in  a  model  of  the  loop  in  which 
the  exit  tests  arc  assumed  to  always  fail.  This  is  called  the  steady  state  model.  'Hie  relationship  between 
the  surface  plan  and  the  steady  state  model  is  represented  using  an  overlay  which  is  explained  in  more 
detail  in  Chapter  Nine. 

The  first  augmentation  recognized  in  the  steady  state  model  of  Lookup-loop  is  the  iterative 
application  of  Car,  shown  in  Fig.  5-4.  On  the  right  hand  side  of  this  overlay  is  the  plan  from  the  library. 
Iterative-application,  which  expresses  the  general  idea  of  repeatedly  applying  a  given  function 
(Action.Op)  to  an  input  provided  by  the  rest  of  the  loop  (Action.Input)  to  produce  an  output 
(Action.Output),  which  may  be  used  by  the  rest  of  the  loop.  The  correspondences  between  this  plan  and 
Lookup-loop  on  the  left  indicate  that  Lookup-loop.One  in  the  steady  state  matches  this  description. 
Similarly,  Fig.  5-5  shows  the  how  Lookup-loop.Three  is  re-described  as  Iterotive-generation.Action. 

Temporal  Abstraction 

Given  that  we  have  decomposed  a  loop  plan  into  these  standard  augmentations,  the  question 
remains  of  how  to  represent  the  connection  between,  say,  the  generation  and  the  application  parts  of  the 
loop.  Temporally,  the  components  of  each  computation  are  interleaved,  but  it  seems  more  logical  to  view 
the  generation  and  application  as  being  composed  in  some  way.  This  section  shows  how  to  construct  this 
viewpoint. 

The  basic  idea  of  temporal  abstraction  is  to  view  ail  the  objects  which  fill  a  given  role  in  a 
recursively  defined  plan  as  a  single  data  structure.1  In  terms  of  Lisp  code,  this  often  corresponds  to 
having  an  explicit  representation  for  the  sequence  of  values  taken  on  by  a  particular  variable  at  a 
particular  point  in  a  loop.  For  example,  in  the  lookup  loop  we  would  like  to  talk  about  the  sequence  of 
objects  iteratively  generated  by  Cdr,  i.e. 

Iterative-generation.Action.Input, 

Iterative-gcneration.TaiLAction.Input, 

Iterative-generation.Tail.Tail.Action.Input, 

which  corresponds  to  the  values  of  bkt  at  the  point  underlined  below  each  time  around  the  loop  (in  the 
steady  state). 


(PROG  (BKT) 

(SETQ  BKT  ...) 

LP  ... 

(S£TQ  BKT  (COR  BKT)) 
(GO  LP)))) 


1.  Both  Shrobc  [64]  and  Waters  [73]  use  the  idea  of  temporal  abstraction,  but  with  slightl)  different  formalizations  than  presented 
here. 
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The  bottom  overlay  in  Fig.  5-6  shows  how  this  abstraction  is  made  using  the  i 
specification.  Iterate,  which  takes  as  input  a  data  structure  called  an  iterator  (which  i 
specialization  of  a  generator),  and  gives  as  output  the  generated  sequence.  An  iterator  has  t\ 
Seed  (the  starting  value  which  will  be  the  first  term  of  the  generated  sequence)  and  the  Op  ( 
which  maps  from  one  term  to  the  next).  As  shown  by  the  hooked  lines  in  Fig.  5-6,  Iterat 
corresponds  to  Iterative-generation.Action.Input  and  lterate.Input.Op  corresponds  t 
generation.Action.Op.  Iteratc.Output  represents  the  sequence  of  inputs  to  Action  on  each 
described  above. 

Iterator  is  an  example  of  a  data  plan  —  the  plan  for  a  data  structure.  This  plan,  ti 
Iterate  and  the  overlays  in  Fig.  5-6,  are  part  of  the  current  library.  An  important  feature 
calculus  is  that  it  allows  the  hierarchical  description  of  data  structures  and  temporal  compi 
single  formalism. 

The  top  overlay  in  Fig.  5-6  makes  the  same  sort  of  abstraction  for  Iterative-applicat 
overlay.  Iterative-application  is  viewed  as  the  input-output  specification.  Map,  which  take 
and  a  function  (Op)  as  inputs,  and  has  a  sequence  as  output  The  terms  of  the  output  sequ 
result  of  applying  the  given  function  to  the  terms  of  the  input  sequence.  In  the  temporal  vie 
sequence  of  Map  is  the  abstraction  of  the  inputs  of  the  Action  of  Iterative-application  on  e; 
The  output  sequence  of  Map  is  the  abstraction  of  the  outputs  of  Action.  Map.Op  coi 
Action.Op.  In  terms  of  the  code  of  lookup,  Map.Input  represents  the  values  of  bkt 
underlined  below  and  Map.Output  represents  the  values  of  entry  (in  the  steady  state). 

(PROG  (BKT  ENTRY) 

(SETQ  BKT  ...) 

LP  ... 

(SETQ  ENTRY  (CAR  BKT It 

(SETQ  BKT  (CDR  BKT)) 

(GO  LP)))) 

Notice  in  this  code  that  the  value  of  bkt  is  the  same  at  the  underlined  point  as  it  is  at 
cor.  This  means  that  in  the  temporal  abstraction  of  Lookup-loop,  the  output  sequence  of  th 
is  the  same  as  the  input  sequence  of  the  Map  step. 

Iterative  terminations  are  also  temporally  abstracted.  The  effect  of  the  null  exit  test  i 
loop  is  modelled  in  the  temporal  view  by  an  input-output  specification  called  Cotruncate, 
takes  as  input  two  sequences  (Cotruncatc.Input  and  Cotruncatc.Co-input)  and 
(Cotruncatc.Critcrion).  Its  output  is  the  truncation  of  the  second  sequence  at  the  earliest  tc 
the  correspond'™  term  of  the  first  sequence  satisfies  the  given  predicate.  This  may 
somewhat  obscua  specification,  but  the  idea  of  two  parallel  sequences  is  in  fact  quite  basic, 
the  standard  plan  for  computing  the  length  of  a  Lisp  list  can  be  naturally  viewed  in  terms  o 
temporal  sequences:  the  natural  numbers,  and  the  sequence  of  cdrs  of  the  list  In  the  co< 
sequence  of  values  of  entry  at  the  underlined  point  (the  output  of  Map)  is  truncated  acc 
Null  predicate  applied  to  the  sequence  of  values  of  bkt  at  the  underlined  point  (the  output  o 
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Figure  5-6.  Temporal  Overlays 
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( PROG  (BKT  ENTRY) 

(SETQ  BKT  ...) 

LP  (COND  ((NULL  BKT  )(RETURN  NIL))) 

(SETQ  ENTRY  (CAR  BKT)) 

(SETQ  BKT  (CDR  BKT)) 

(GO  LP)))) 

In  the  next  section,  we  will  see  how  this  pattern  of  Generate,  Map  and  Cotruncate  using  Car,  Cdr 
and  Null,  is  recognized  as  the  standard  plan  for  generating  a  list  in  Lisp. 

The  null  exit  test  above  has  also  been  recognized  as  part  of  the  Terminated-iterative-scarch  plan  in 
lookup  (the  other  exit  test  is  eq).  Fig.  5-7  shows  an  overlay  from  the  library  which  views  Terminated- 
iterative-search  as  the  temporal  implementation  of  a  standard  test  on  sets  called  Any.  Given  a  set 
(Any. Uni  verse)  and  a  predicate  (Any.Criterion),  this  test  succeeds  if  there  is  a  member  of  the  set  which 
satisfies  the  predicate,  and  returns  such  an  object  (Any .output);  otherwise  it  fails.  In  the  temporal  overlay 
ofTerminated-iterativc-search  as  Any  shown  in  Fig.  5-7,  Any.Universe  corresponds  to  the  set  of  inputs  to 
the  second  exit  test  of  the  search.1 2  In  the  code  of  lookup,  this  is  the  set  of  values  of  entry  at  the  point 
underlined  below. 


(PROG  (BKT  ENTRY) 

(SETQ  BKT  ...) 

LP  (CONO  ((NULL  BKT)(RETURN  NIL))) 

(SETQ  ENTRY  (CAR  BKT)) 

(COND  ((EQ  (CAR  ENTRY!  KEY) 

(RETURN  ENTRY))) 

(SETQ  BKT  (COR  BKT)) 

(GO  LP)))) 

This  overlay  also  illustrates  a  common  form  of  temporal  abstraction,  in  which  we  talk  about  the  set 

•y 

of  objects  filling  a  given  role  in  a  recursive  plan,  ignoring  their  temporal  order.  As  we  shall  see,  this 
turns  out  to  be  the  appropriate  level  of  abstraction  for  this  example. 

The  relationship  between  the  temporal  abstractions  of  the  various  parts  of  lookup-loop  is 
illustrated  in  Fig.  5-8.  This  figure  shows  all  four  overlays  discussed  in  this  section  applied  to  Lookup-loop 
simultaneously.  In  order  to  reduce  clutter,  only  the  data  flow  constraints  in  Lookup-loop  and  the 
correspondences  which  involve  temporal  abstraction  are  drawn.  Notice  that  many  of  the  temporal 
sequences  on  the  right  are  the  abstraction  of  roles  of  Lookup-loop  which  are  constrained  by  data  flow  to 
be  the  same.  In  particular,  Itcrate.Output  is  the  same  sequence  as  Map.Input  and  Cotruncate-Input,  and 
Map.Output  is  the  same  sequence  as  Cotruncate.Co-inpuL 

Some  of  the  temporal  correspondences  in  Fig.  5-8  involve  different  steady  state  models.  For 
example,  Cotruncatc.Input  is  the  temporal  abstraction  of  Lookup-loop.One.Output  in  the  steady  state 
model  with  no  exit  tests;  Cotruncatc.Output  is  the  sequence  which  includes  the  effect  of  the  Null  test 
This  detail  cannot  be  shown  conveniently  in  this  figure,  but  is  explained  ii.  the  next  section. 


1.  More  precisely,  Any.Universe  corresponds  10  Ihe  set  of  objects  which  would  be  searched  if  there  were  no  member  satisfying  the 
predicate.  This  abstraction  involves  forming  a  steady  state  model  in  which  exit  Two  always  fails. 

2.  Formally  this  abstraction  is  done  in  two  steps:  first  a  temporal  sequence  abstraction  is  made:  and  then  this  ordered  Stricture  is 
viewed  as  the  implementation  of  a  set.  This  will  be  explained  more  fully  in  Chapter  Nine. 
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Figure  5-8.  Temporal  Abstractions  of  lookup  Loop, 
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The  relationship  between  the  output  sequence  of  Cotruncate  and  Any.Universe  is  represented  by 
an  overlay,  Scquencosct,  which  expresses  in  g:ncral  how  to  view  a  sequence  as  a  set  Such  overlays 
between  abstract  descriptions  are  typical  as  analysis  progresses  beyond  the  surface  plan. 

In  summary.  Fig.  5-9  shows  an  overview  of  the  plans  and  overlays  used  in  the  loop  analysis  thus  far. 
The  names  of  the  plans  are  arranged  in  a  hierarchy  which  reflects  the  order  in  which  they  must  be 
recognized.1  Each  plan  depends  on  the  recognition  of  the  plans  below  it  as  indicated  by  the  vertical  lines 
in  the  figure.  Flans  at  the  same  level  in  the  hierarchy  may  be  recognized  in  any  order.  Overlays  from  the 
library  used  in  this  analysis  are  drawn  as  vertical  lines  with  arrow  heads  to  suggest  that  once  the  lower 
plan  is  recognized,  the  library  is  searched  to  suggest  a  more  abstract  description.  The  other  lines 
represent  pattern  matching  that  is  done  specifically  for  this  example.  Notice  that  the  analysis  of  a 
program  is  not  strictly  hierarchical.  Distinct  nodes  at  one  level  may  share  parts  of  the  same  plan  at  a  level 
below.  For  example,  the  recognition  of  both  iteration  and  iterative-application  share  the  Itcrative-steady- 
state  plan.  Conversely,  the  fact  that  a  given  plan  or  role  has  been  used  in  one  overlay,  does  not  make  it 
ineligible  for  use  in  others. 

5.5  Bottom-up  Recognition 

It  is  natural  to  divide  the  analysis  of  lookup  roughly  into  three  layers,  as  shown  in  Fig.  5-10.  The 
bottom  layer  is  loop  analysis,  as  described  in  the  preceding  section.  The  middle  and  top  layers  are 
distinguished  mostly  by  the  complexity  of  the  data  structures  involved.  The  plans  in  the  middle  layer 
involve  only  basic  data  structures  such  lists,  sequences  and  sets.  The  effect  of  temporal  abstraction,  which 
is  the  final  step  of  loop  analysis,  is  to  re-describe  looping  computations  in  terms  of  these  basic  data 
structures.  The  top  layer  of  analysis  in  this  example  involves  the  relatively  complex  and  specialized  hash 
table  data  structure. 

My  intuition  is  that  these  general  layers  of  abstraction  are  not  specific  to  this  example,  though  in 
larger  programs  there  would  be  more  upper  layers.  This  means  that  the  plan  library  itself  can  be  roughly 
divided  into  layers.  Most  of  the  plans  in  the  current  library  are  in  the  middle  layer  involving  lists, 
sequences,  sets,  and  directed  graphs.  Presently  the  only  more  complicated  data  plans  have  to  do  with 
hash  tables. 

The  three  layers  of  description  in  this  example  also  suggest  a  three  phase  strategy  for  automating 
analysis.  The  first  phase  is  the  specialized  algorithm  for  loop  analysis  described  in  the  preceding  section. 
The  second  phase  can  be  thought  of  as  bottom-up  pattern  recognition,  in  which  the  standard  plans 
involving  basic  data  structures  familiar  to  every  experienced  programmer  arc  recognized.  The  third  phase 
of  analysis  depends  on  being  given  some  high  level  description  of  what  the  whole  program  is  trying  to  do, 
so  that  top-down  analysis  by  synthesis  can  be  used.  An  alternative  scenario,  in  which  no  top  level 
description  is  given,  is  not  considered  here.2  These  three  phases  agree  with  my  own  introspection  and 


1.  Some  of  these  steps  have  been  skipped  over  in  this  initial  exposition,  but  arc  included  here  for  future  reference. 

2.  Such  a  scenario  would  presumably  involve  a  much  stronger  control  structure  for  hypothesis  formation  and  testing. 


r 
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Figure  5-9.  Overview  of  Analysis  of  lookup  Loop. 


Figure  5-10.  Layers  in  Analysis  of  lookup. 
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experience  in  analyzing  previously  unseen  programs.  It  would  be  interesting  to  conduct  some 
experiments  to  verify  the  psychological  validity  of  this  model 

The  rest  of  this  section  describes  the  particular  plans  in  the  middle  layer  of  the  analysis  of  lookup, 
which  are  recognized  bottom-up.  The  next  section  describes  the  plans  in  the  top  layer,  which  are 
recognized  top-down,  and  how  the  two  layers  are  connected. 

As  we  can  see  in  Fig.  5-10,  there  are  several  plans  in  the  middle  layer  which  may  be  recognized  in 
any  order.  We  begin  with  the  plan  Car+cdr+null.  shown  in  Fig.  5-11,  which  has  three  steps:  One  (an 
instance  Iterate),  Two  (an  instance  of  Map)  and  Three  (an  instance  of  Cotruncate).  'Hie  data  flow 
between  the  roles  in  this  plan  is  the  same  as  between  the  overlays  of  Iterate,  Map  and  Cotruncate  on 
Lookup-loop  described  in  the  preceding  section  and  shown  in  Fig.  5-8.  This  plan  in  general  is  called 
Truncatcd-list-gcncration.  Car+cdr+null  is  a  specialization  in  which  the  generating  function  is  Cdr,  the 
function  being  applied  by  Map  is  Car,  and  the  criterion  of  Cotruncate  is  Null.1 

Returning  to  lookup,  we  have  now  come  as  far  as  recognizing  that  the  initial  input  to  the  loop  (the 
initial  value  of  bkt)  is  a  Lisp  list.  The  temporal  abstraction  of  the  second  exit  from  the  loop  as  Any  goes 
one  step  further  and  views  this  list  as  the  implementation  of  a  set.  From  the  analysis  of  lookup  alone,  it  is 
not  clear  whether  or  not  this  list  may  contain  duplicates.  In  the  plan  library,  the  implementation  of  sets  as 
irredundant  lists  is  represented  as  a  specialization  of  the  overlay  used  here. 

There  are  two  more  small  points  to  be  covered.  The  first  two  steps  of  Lookup-surface  (please  refer 
back  to  Fig.  5-1)  need  to  be  analyzed  as  the  application  of  a  functional  composition,  Composed- 
<®functions,  described  in  Chapter  Four.  This  is  a  common  cliche  which  is  needed  here  to  put  the  surface 
plan  in  a  form  which  will  connect  with  the  top-down  recognition  phase  of  the  next  section. 

Another  feature  of  the  surface  plan  of  lookup  to  be  recognized  bottom-up  is  that  the  final  output 
object  (Lookup-surface.End.Output),  which  in  the  code  is  the  value  returned  by  the  lambda  expression, 
can  be  viewed  as  a  flag.  Flags  are  a  minor  programming  technique  (formalized  in  the  appendix).  The 
basic  idea  is  that  the  result  of  a  test  (in  this  case  Any)  is  encoded  in  a  data  object  so  that  the  information 
discovered  by  the  test  can  be  recovered  after  a  join.  (Control  is  joined  here  because  Lisp  docs  not  allow 
multiple  return  points.)  The  information  encoded  in  the  flag  is  recovered  later  by  testing  the  object  with 
a  given  predicate  (Null  in  this  case). 

5.6  Top-down  Recognition 

The  main  point  of  this  section  to  illustrate  how  a  moderately  complex  data  structure,  such  as  a  hash 
table,  is  decomposed  in  terms  of  the  plan  library.  This  section  also  introduces  an  important  heuristic 
principle  which  is  applicable  to  both  analysis  and  synthesis  by  inspection. 

The  comment  at  the  beginning  of  the  code  for  the  symbol  table  program  in  Table  5-A  reads:  ”a  set 
of  entries  is  implemented  as  a  hash  table  on  keys”.  In  the  top-down  part  of  this  analysis  scenario,  we 
make  use  of  this  comment  to  retrieve  the  top  few  plans  in  the  analysis  of  lookup  from  the  library. 


1.  We  always  try  to  recognize  the  most  specialized  version  of  a  plan  where  possible. 
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Figure  5*11.  Plan  Tor  Generating  a  Lisp  List. 
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At  the  highest  level  of  abstraction,  we  are  dealing  with  the  implementation  of  a  set.  This  set  is 
implemented  as  a  hash  table  on  keys.  In  the  analysis  presented  here,  this  implementation  is  decomposed 
into  three  basic  ideas:  discrimination,  hashing  and  keys. 

According  to  the  plan  library,  a  discrimination  function  maps  some  domain  (in  this  example, 
"entries”)  onto  a  set  of  sets,  called  buckets.  Such  a  function  can  be  viewed  as  implementing  a  set  wherein 
a  given  object  is  a  member  if  and  only  if  it  is  a  member  of  the  bucket  obtained  by  applying  the 
discrimination  function  to  that  object.  Operations  on  a  set  implemented  this  way  reduce  to  operations  on 
a  single  bucket,  which  is  often  more  efficient,  especially  in  the  case  of  operations  which  involve  search. 
This  idea  is  also  part  of  many  other  data  structures,  such  as  discrimination  nets. 

The  basic  idea  of  hashing  is  to  implement  a  discrimination  function  as  the  composition  of  two 
functions.  The  first  function,  called  the  hash  function,  maps  the  domain  of  the  discrimination  onto  the 
set  of  valid  indices  for  a  sequence.  The  second  function  is  a  sequence,  called  the  table,  whose  indices  are 
the  range  of  the  hash  function.  The  utility  of  this  decomposition  is  that  modifications  to  the 
discrimination  function  may  be  achieved  by  modifying  only  the  table. 

Discrimination  on  keys  is  also  an  implementation  idea  involving  functional  decomposition.  In  a 
keyed  discrimination,  each  member  of  the  implemented  set  has  an  associated  key.  In  the  symbol  table 
example,  the  function  from  entries  to  keys  is  Car.  The  discrimination  function  in  this  implementation  is 
the  composition  of  two  functions:  the  first  function  is  the  key  function;  the  second  function  maps  from 
the  set  of  keys  to  the  buckets.  The  utility  of  this  decomposition  is  that  for  certain  operations,  such  as 
associative  retrieval,  we  are  given  only  the  key  of  an  entry,  rather  than  the  entry  itself. 

To  summarize,  all  three  of  these  ideas  are  combined  in  the  symbol  table  example  as  follows.  At  the 
top  level  we  have  a  set  implemented  as  a  keyed  discrimination.  The  key  function  is  Car,  and  the  function 
from  keys  to  buckets  is  implemented  as  a  hash  table.  The  hash  function  of  the  hash  table  is  Hashl  (hash); 
the  table  is  an  abstraction  of  Vectorl  (tbi),  in  which  it  is  viewed  as  a  a  sequence  of  sets,  each  of  which  is 
implemented  as  Lisp  lists. 

Being  able  to  formally  analyze  a  data  structure  design  in  this  way  is  a  new  and  important  result 
This  analysis  gives  a  deep  insight  into  the  logical  structure  of  this  implementation  and  captures  what  it  has 
in  common  with  other  implementations.  It  also  decomposes  the  verification  of  the  design,  since  each 
component  can  be  separately  verified.  This  aspect  of  the  plan  calculus  is  a  contribution  towards  current 
efforts  in  computer  science  to  develop  an  "algebra"  of  practical  programming  constructs.  Others  working 
in  this  effort  have  concentrated  on  the  composition  of  procedural  constructs  [4],  similar  to  the  ideas 
described  in  the  loop  analysis  section,  or  have  worked  only  with  simpler  data  structures  [50]. 

Ilie  Maximal  Sharing  Heuristic 

There  arc  several  different  plausible  accounts  of  how  the  analysis  described  above  could  be  derived 
automatically,  given  the  code  and  comments  in  Table  5-A,  the  bottom-up  analysis  described  in  the 
preceding  section,  and  the  current  plan  library.  All  of  these  accounts  involve  using  what  I  call  the 
maximal  sharing  heuristic.  The  origin  of  this  heuristic  is  in  program  synthesis,  but  it  also  turns  out  to 
provide  an  elegant  solution  to  the  problem  in  program  analysis  of  connecting  bottom-up  recognition  with 
top-down  analysis  by  synthesis. 
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In  synthesis,  the  maximal  sharing  heuristic  is  applied  at  each  implementation  step.  The  basic  idea 
of  the  heuristic  is,  rather  than  always  adding  new  structure  for  an  implementation,  to  reuse  as  many  parts 
as  possible  of  other  plans  in  the  current  design  which  satisfy  the  constraints  of  the  current  implementation 
plan.  The  effect  of  this  heuristic  is  to  cause  there  to  be  a  (locally)  maximal  amount  of  sharing  in  the 
analysis  hierarchy.  The  motivations  for  this  heuristic,  and  its  application  in  synthesis  are  elaborated  in 
Chapter  Six. 

The  way  to  apply  this  heuristic  in  analysis  is  to  view  the  parts  of  the  bottom-up  analysis  as  parts  of 
the  current  design  which  are  available  for  reuse.  Whenever  a  part  of  the  bottom-up  analysis  gets  used  in  a 
top-down  synthesis  step,  a  connection  has  been  achieved  between  the  two  phases  of  analysis.  This  holds 
out  the  promise  that  a  module  written  for  automated  synthesis  which  obeys  this  heuristic  may  be  used 
without  change  in  automated  analysis. 

Another  nice  feature  of  this  approach  is  that  it  suggests  two  fairly  intuitive  notions  of  partial 
analysis.  One  situation  is  when  you  can’t  find  parts  of  the  program  you  expect,  lhis  corresponds  to  when 
parts  of  the  top-down  synthesis  never  getting  connected  with  the  bottom-up  analysis.  In  an  interactive 
system,  this  could  signal  a  potential  bug  or  at  least  a  request  for  further  explanation  from  the  user.  The 
complementary  situation  is  when  parts  of  the  bottom-up  analysis  are  never  used  by  the  top-down  phase. 
The  most  natural  interpretation  of  this  situation  is  that  the  programmer  is  using  plans  which  are  not  in  the 
current  library.  An  interesting  topic  for  future  research  is  the  possibility  of  isolating  and  generalizing 
these  novel  parts  of  a  program  so  that  new  plans  can  automatically  be  added  to  the  library. 

Returning  now  to  lookup,  let  us  follow  one  account  of  how  the  final  steps  of  analysis  might  proceed. 
It  may  help  to  refer  to  Fig.  5-10  to  follow  this  explanation. 

The  first  step  in  the  top-down  analysis  is  to  conclude  that  the  set  operation  implemented  by  lookup 
is  associative  retrieval.  This  could  be  deduced  from  the  name  of  the  procedure,  or  by  looking  at  the  types 
of  its  inputs  and  outputs  and  the  fact  that  it  has  two  cases. 

The  library  overlay  for  implementing  associative  retrieval  from  a  keyed  discrimination  is  shown  in 
Fig.  5-12.  The  input-output  specification  for  associative  retrieval  on  the  right  hand  side  is  called  Retrieve. 
It  is  a  test  with  three  inputs,  a  set  (Universe),  the  key  function  (Key),  and  an  input  key  (Input),  and  one 
output.  If  there  exists  a  member  of  the  set  with  the  given  key,  then  the  test  succeeds  and  returns  such  a 
member;  otherwise  it  fails.  On  the  left  hand  side  of  the  overlay  we  have  the  typical  two  step  plan  for 
implementing  a  set  operation  on  a  discrimination:  appiy  the  discrimination  function  to  fetch  the 
appropriate  bucket,  and  then  perform  the  same  operation  on  the  bucket.  This  general  implementation 
works  for  adding  and  removing  a  member,  and  certain  kinds  of  retrieval.  It  docs  not  work  for  other 
operations  such  as  union  or  intersection. 

The  first  step  (Discriminate)  of  the  plan  on  the  left  of  Fig.  5-12  is  thus  constrained  to  be  an  instance 
of  (<i  Function,  in  which  the  function  being  applied  is  the  discrimination  function  from  keys  to  buckets. 
The  maximal  sharing  heuristic  suggests  using  the  @  Function  recognized  bottom-up  (sec  Fig.  5-10)  in  this 
role.  Recall  that  this  <a  Function  is  itself  implemented  as  the  composition  of  tw  o  instances  of  (^Function, 

(ARRAYFETCH  TBL  (HASH  KEY)), 

from  which  we  can  conclude  that  the  hashing  function  is  Hashl  and  die  table  is  Vectorl. 


DO  CHAPTER  FIVE 


T>iic*i»n«n«tL+  rt+ri  tvt>  rcFtitve- 


Figure  5-1 2.  Associative  Retrieval  From  a  Keyed  Discrimination. 
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The  second  step  (10  of  the  plan  on  the  left  of  Fig.  5-12  is  constrained  to  be  an  instance  of  Retrieve, 
applied  to  the  bucket  fetched  in  step  One.  According  to  the  second  comment  at  the  front  of  the  code  (see 
Table  5-A),  "the  buckets  are  implemented  as  lists".  The  only  implementation  in  the  library  for  Retrieve 
on  sets  other  than  those  implemented  as  discriminations  is  as  Any  (an  input-output  specification 
introduced  earlier  in  this  chapter)  in  which  the  criterion  is  a  composite  predicate.  The  form  of  this 
predicate  is  to  test  whether  the  key  of  a  given  object  is  equal  to  some  constant  If  the  key  function  is  Car, 
this  comes  down  to  Lisp  code  like  the  following  test  in  lookup. 

(COMO  ((EQ  (CAR  ...)  KEY) 

...» 

The  sharing  heuristic  suggests  recognizing  the  bottom-up  Any  specification  as  implementing  the 
bucket  Retrieve  in  this  way.  In  order  for  this  to  be  the  case,  the  key  function  of  the  hashing 
implementation  must  be  Car. 

This  completes  the  analysis  of  lookup.  Let  me  emphasize  that  the  last  few  paragraphs  are  only  one 
of  many  possible  accounts  of  how  the  top-down  recognition  could  be  accomplished.  There  are  many 
other  strong  clues  in  this  program,  particularly  in  the  types  of  objects.  For  example,  the  only  candidate 
for  the  table  part  of  the  hash  table  (by  virtue  of  being  a  vector)  is  Vectorl;  the  only  candidate  for  the  hash 
function  (by  virtue  of  being  a  numerical  function)  is  Hashl. 


I 
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CHAPTER  SIX 

SYNTHESIS  BY  INSPECTION 


6.1  Introduction 

A  library  of  plans,  such  as  presented  in  Chapter  Three,  opens  up  many  new  possibilities  for  what  an 
interactive  program  development  system  can  do  to  help  a  user  synthesize  programs.  This  chapter  is  an 
exploration  into  some  of  these  new  possibilities.  This  chapter  also  shows  the  use  of  the  plan  calculus  as  a 
design  language,  and  picks  up  where  Chapters  Two  and  Five  leave  off  in  showing  how  the  plans  in  the 
current  library  are  used  together  in  a  complete  example. 

In  broad  terms,  the  plan  library  represents  a  significant  body  of  knowledge  about  programming 
which  is  shared  between  the  user  and  the  system,  which  has  never  been  the  case  before.  The  most 
advanced  current  program  development  systems  (e.g.  [71,14])  have  some  built-in  knowledge  of 
programming  language  syntax  and  type  restrictions,  but  none  include  the  range  or  kind  of  knowledge 
represented  in  the  plan  library. 

This  chapter  presents  a  simple  scenario  of  interactive  program  synthesis  in  which  the  working 
medium  is  the  plan  calculus  rather  than  Lisp  code.  Code  is  generated  only  as  a  final  translation  of  the 
synthesized  surface  plan.  The  order  of  development  in  this  scenario  is  primarily  top-down.  The  user 
progressively  refines  an  initial  abstract  specification  by  application  of  overlays  from  the  plan  library.  This 
scenario  is  thus  restricted  to  programs  which  can  be  completely  analyzed  using  plans  in  the  library  alone. 
This  scenario  also  portrays  an  expert  user  who  is  familiar  with  the  plan  library. 

The  fundamental  interaction  between  the  system  and  the  user  in  this  scenario  is  for  the  system  to 
propose  a  menu  of  overlays  from  the  library  which  are  applicable  to  the  current  design  plan,  and  for  the 
user  to  choose  between  them.  In  this  way,  the  user  guides  the  synthesis  in  top-down  fashion.  The  user 
also  intervenes  at  certain  crucial  points  in  the  development  to  introduce  new  plans  from  the  library,  and 
to  suggest  rcanalysis  of  the  current  design  which  leads  to  a  more  efficient  implementation.  In  addition  to 
retrieving  overlays  from  the  library,  the  system  also  needs  to  be  able  to  spontaneously  propagate  some 
information  and  construct  specializations  of  library  plans  appropriate  to  the  current  design.  This  implies 
a  deductive  component  in  the  system,  whose  operation  will  not  be  discussed  here,  since  it  is  part  of 
related  research  reported  elsewhere  [64], 

Deductive  capabilities  arc  also  required  to  apply  the  maximal  sharing  heuristic.  Ihe  basic  idea  of 
this  heuristic,  as  described  in  Chapter  Five,  is  to  build  plans  which  share  as  much  structure  as  possible.1 
The  motivation  for  this  heuristic  is  that  it  often  leads  to  more  efficient  programs.  It  is  applied  in  synthesis 
each  time  an  overlay  is  used  to  further  implement  some  part  of  the  current  design.  To  apply  the  heuristic, 


1.  Sacerdoti,  in  his  work  on  general  problem  solving  |60]  uses  a  similar  heuristic  of  the  form  "use  existing  objects  whenever 
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the  system  needs  to  know  whether  a  subset  of  the  roles  on  the  left  hand  side  of  an  overlay  can  be 
identified  with  roles  of  other  existing  plans  in  the  current  design,  while  being  consistent  with  both  the 
constraints  of  the  plan  on  the  left  hand  side  of  the  overlay  and  the  existing  constraints  on  the  other  roles. 

With  the  maximal  sharing  heuristic  in  operation,  synthesis  using  overlays  becomes  a  mixture  of 
progressive  refinement  and  constraint.  In  the  refinement  steps,  an  overlay  is  used  to  expand  the  current 
design  in  a  tree-like  fashion,  by  adding  more  detail  at  one  of  the  terminal  nodes.  Alternatively,  whenever 
sharing  is  established  in  the  application  of  an  overlay,  the  effect  to  is  add  further  constraints  to  the  current 
design. 

The  synthesis  scenario  in  this  section  is  divided  into  three  distinct  phases:  data  structure  design, 
procedure  implementation,  and  code  generation.  In  the  first  phase,  the  user  lays  out  the  implementation 
of  the  hash  table  data  structure  using  overlays  between  data  plans.  The  second  phase,  procedure 
implementation,  involves  refining  the  input-output  specifications  for  associative  retrieval,  addition,  and 
deletion  on  the  hash  table  down  to  the  level  of  Lisp  surface  plans.  The  final  phase  is  the  generation  of 
Lisp  code  from  surface  plans. 

The  major  purpose  of  this  scenario  is  to  demonstrate  what  it  could  be  like  to  develop  programs 
interactively  with  a  system  that  had  significant  programming  knowledge  in  the  form  of  a  plan  library. 
The  particular  order  of  development  is  not  in  any  way  canonical.  Any  realistic  such  system  will  have  to 
be  based  on  a  mixed  initiative  model  which  allows  the  user  to  tailor  the  order  of  development  to  the 
particular  programming  task  at  hand.  As  in  the  scenario  of  Chapter  Two,  lines  typed  by  the  system  are 
shown  in  upper  case;  lines  typed  by  the  user  are  shown  in  lower  case. 

6.Z  Data  Structure  Design 

In  this  section,  the  user  designs  the  main  data  structure  of  the  symbol  table  program,  starting  with  a 
description  of  it  as  a  set  of  entries,  and  culminating  with  its  implementation  as  a  keyed  discrimination  in 
which  the  function  from  keys  to  buckets  is  implemented  by  hashing. 

>  let  an  "entry*  be  a  data  structure. 

>  "symbol"  (an  atom)  Is  part  of  an  entry. 

>  "Info"  Is  part  of  an  entry. 

The  user  begins  by  defining  a  new  data  plan  which  is  particular  to  the  programming  task  at  hand. 
This  definition  becomes  a  part  of  the  permanent  documentation  of  the  program.  An  "entry"  is  defined  as 
a  data  structure  with  two  fields,  named  Symbol  and  Info.  The  Symbol  field  contains  a  Lisp  atom; 
nothing  is  said  about  the  Info  field. 

>  let  a  "symbol  table'  be  a  finite  set. 

>  for  .all  "x"  If  x  belongs  to  a  symbol  table,  then  x  Is  an  entry. 

The  user  now  defines  a  symbol  table  as  finite  set  of  entries.  The  rest  of  this  section  is  concerned 
with  implementing  this  set. 
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>  i 

APPLICABLE  IMPLEMENTATIONS  FOB :  SYMBOL-TABLE  (A  FINITE-SET) 

1.  LIST 

2.  SEQUENCE 

3.  LABELLED-THREAD 

4.  DISCRIMINATION  FUNCTION 

T  1 

The  user  transfers  initiative  temporarily  to  the  system  by  typing  an  empty  command  line.  The  basic 
action  of  the  system  in  this  situation  is  retrieve  from  the  library  all  overlays  which  are  applicable  to  the 
current  design.  In  general,  this  includes  all  overlays  whose  right  hand  sides  (or  specializations  or 
extensions  of  them)  appear  in  the  current  design.  Furthermore,  the  system  in  general  first  proposes 
overlays  for  a  whole  plan  before  trying  to  find  overlays  for  any  of  its  roles.  In  this  case,  the  system 
retrieves  four  overlays:  the  first  three  are  for  implementing  sets  as  lists,  sequences,  and  labelled  threads, 
respectively:  the  fourth  is  for  implementing  a  finite  set  as  a  discrimination.  The  user  chooses  the  fourth 
overlay  as  the  one  to  apply,  and  the  system  responds  by  instantiating  the  left  hand  side  of  the  overlay, 
propagating  the  appropriate  information  through  the  correspondences. 

LET  "DISCRIMINATION!”  BE  THE  IMPLEMENTATION  OF  SYMBOL-TABLE  AS  A 

DISCRIMINATION  FUNCTION. 

Thus  Discrimination!  is  a  discrimination  function  on  entries,  which  is  the  implementation  of 
Symbol-table.  Fig.  6-1  shows  the  complete  implementation  of  Symbol-table,  as  it  will  be  developed  in 
this  section.  Implementation  relationships,  such  as  between  Discrimination!  and  Symbol-table,  are 
shown  in  this  figure  as  vertical  arrows  pointing  up  from  the  instance  of  the  left  hand  side  to  the  instance 
of  the  right  hand  side.  (This  is  the  same  convention  as  was  used  in  Chapter  Five.)  In  this  figure,  and  the 
other  similar  one  is  this  chapter,  vertical  lines  without  arrow  heads  denote  part-whole  relationships,  with 
the  role  names  indicated. 

>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR:  DISCRIMINATION!  (A  DISCRIMINATION) 

1.  COMPOSED- FUNCTIONS 

2.  UNARY-LAMBDA 

»  l 

The  scenario  continues  with  the  system  proposing  applicable  overlays  for  Discrimination!.  In  this 
case,  the  only  applicable  overlays  are  for  functions  in  general,  of  which  there  are  two  in  the  current 
library:  a  function  can  cither  be  implemented  as  the  composition  of  two  other  functions,  or  it  can  be 
implemented  directly  in  Lisp  as  a  lambda  expression.  The  user  chooses  the  first  option. 

SPECIALIZATIONS  OF:  COMPOSED- FUNCTIONS 

1.  HASHING 

2.  KEYED-DISCRIMINATION 

»  l 


LET  "KEYEO-OISCRIMINATIONI"  8E  THE  IMPLEMENTATION  OF  DISCRIMINATION!  AS  A 
KEYED-DISCRIMINATION. 
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Figure  6*1.  Implementation  of  the  Symbol  Table. 
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Before  applying  an  overlay,  the  system  checks  in  the  library  for  any  specializations  or  extensions  of 
the  plan  on  the  left  hand  side.  If  any  exist,  the  user  is  given  a  chance  to  choose  one.  In  this  case,  the 
system  finds  two  specializations  of  Composed-functions,  namely  Hashing  and  Keyed-discrimination. 
The  user  chooses  the  second,  causing  the  system  to  instantiate  Kcycd-discriminationl  as  the 
implementation  of  Discriminationl.  (The  user  could  have  responded  "no",  causing  the  system  to 
instantiate  an  instance  of  Composed- functions  with  no  further  constraints.) 

>  i 

ELIGIBLE  SHARING  FOR:  KEYED-DISCRIMINATION1 .ONE  (’THE  KEY  FUNCTION*) 

.  1.  SYMBOL 

2.  INFO 

f  1 

LET  SYMBOL  BE  THE  KEY  FUNCTION  OF  KEYED-DISCRIMINATION! . 

LET  "FUNCTI0N1"  THE  BUCKET  FUNCTION  OF  KEYED- DISCRIMINATION!. 

The  instantiation  of  Keycd-discriminationl  gives  us  our  first  opportunity  to  see  the  maximal 
sharing  heuristic  in  action.  The  system  above  has  searched  for  existing  objects  in  the  current  design 
which  could  fill  the  roles  of  Keyed-discriminationl  and  satisfy  the  constraints  of  the  Keyed- 
discrimination  plan.  The  first  filter  on  this  search  can  be  the  object  types  —  roles  One  and  Two  of  a 
keyed  discrimination  must  be  functions.  There  ?.re  three  functions  in  the  current  design:  Symbol,1  Info 
and  Discriminationl.  Discriminationl  can  imn  ediately  be  eliminated  from  consideration  because  it  is 
above  Keyed-discriminationl  in  the  refinement  tree,  so  that  sharing  with  it  would  lead  to  a  meaningless 
circularity.  Symbol  and  Info  can  be  rejected  for  role  Two  of  Keyed-discriminationl,  since  the  range  of 
this  function  is  constrained  to  be  finite  sets.  This  leaves  the  possibility  of  Symbol  or  Info  filling  role  One 
of  Keyed-discrimination,  which  the  system  proposes  as  shown  above.  The  user  chooses  a  keyed 
discrimination  on  the  symbol  field  of  entries.  The  system  completes  this  frame  of  the  interaction  by 
instantiating  Functionl,  a  function  from  Lisp  atoms  to  finite  sets,  to  fill  role  Two.  (Again,  the  user  could 
have  responded  "no”  to  the  question  above,  in  which  case  a  new  object  would  be  instantiated  for  role 
One  as  well  as  for  role  Two.) 

>  i 

APPLICABLE  IMPLEMENTATIONS  FOR:  FUNCTION!  (A  FUNCTION) 

1.  COMPOSED-FUNCTIONS 

2.  UNARY-LAMBOA 

r  l 

SPECIALIZATIONS  OF:  COMPOSED- FUNCTIONS 

1  HASH I HC 

2.  KEYED-OISCIIINIIIATIOIf 

f  1 

LET  ’HASHING!*  BE  THE  IMPLEMENTATION  OF  FUNCTION1  AS  A  HASHING. 

In  this  next  frame,  Functionl  is  implemented  as  a  hash  table,  Hashingl. 


1.  Role  names  are  Formally  function*. 
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>  i 

LET  "HASH1"  BE  THE  HASH  FUNCTION  OF  HASHIN61. 
LET  "TABLET  BE  THE  TABLE  OF  HASHING1. 


Since  there  arc  no  existing  objects  which  can  fill  the  roles  of  Hashingl,  the  system  instantiates  Hashl  and 
Tablel. 


>  implement  the  buckets  of  tablet. 


After  letting  the  system  carry  the  initiative  for  a  few  steps,  the  user  intervenes  here  with  a  command 
to  retrieve  overlays  from  the  library  for  implementing  the  buckets  of  the  discrimination  (the  range 
elements  of  Tablel). 


APPLICABLE  IMPLEMENTATIONS  FOR:  BUCKETS  OF  TABLE1  (A  FINITE-SET) 

1.  LIST 

2.  SEQUENCE 

3.  LABELLED-THREAD 

4.  DISCRIMINATION 

»  1 

SPECIALIZATIONS  OF:  LIST 
1.  IRREDUNDANT -LIST 

t  1 

LET  'TABLE2*  BE  THE  IMPLEMENTATION  OF  TABLE1  SUCH  THAT 

FOR  ALL  "I"  ANO  "X".  IF  TERM  I  OF  TABLEZ  EQUALS  X.  THEN  X  IS  THE 

IMPLEMENTATION  OF  TERM  I  OF  TABLE  1  AS  AN  IRREDUNDANT -LIST. 


The  user  above  chooses  to  implement  the  buckets  as  lists,  and  in  particular  lists  without  duplicates. 
The  system  responds  by  instantiating  Table2  which  is  related  to  Tablel  an  overlay  in  which  each  term  of 
Tablc2  (an  irredundant  list)  is  viewed  as  the  corresponding  term  of  Tablel  (a  finite  set). 

This  completes  the  part  of  the  data  structure  design  that  is  programming  language  independent  (see 
Fig.  6-1). 

Lisp-Specific  Data  Structure  Implementation 


The  remaining  few  steps  in  this  section  are  involving  with  bringing  the  data  structure  design  down 
to  the  level  of  Lisp  data  objects. 


>  Implement  an  entry  as  a  dotted  pair,  such  that 
entry. symbol *dotted-pa ir.car 'and  entry . 1nfo-dotted-pa1r.cdr 


Here  the  user  specifics  the  implementation  of  entries  as  dotted  pairs  such  that  the  Symbol  function 
is  implemented  by  Car  and  the  Info  function  by  Cdr. 


>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR:  HASH1  (A  HASHING) 

1.  COMPOSED-FUNCTIONS 

2.  UNARY- LAMBDA 

T  1 


Hashl  is  to  be  implemented  as  a  Lisp  procedure,  which  will  be  coded  later. 


Illf  'll li  —Ml  n* 
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>  i 

APPLICABLE  IMPLEMENTATIONS  FOR:  BUCKETS  OF  TABLE2  (AN  I RREOUNOANT -LIST) 

1.  UPPER-SEGMENT 

2.  DOTTED-PAIR 

3.  LIST -GENERATION 

r  2 

LET  "TABLES"  BE  THE  IMPLEMENTATION  OF  TABLE2  SUCH  THAT 

FOR  ALL  "I"  AND  "X".  IF  TERM  I  OF  TABLE3  EQUALS  X.  THEN  X  IS  THE 

IMPLEMENTATION  OF  TERM  I  OF  TABLE2  AS  A  DOTTED-PAIR. 


The  range  elements  (buckets)  of  Table2  are  not  yet  implemented  as  Lisp  data  objects.  The  system 
suggests  three  overlays  for  implementing  lists.  The  user  chooses  the  direct  route  of  implementing  lists  as 
dotted  pairs. 


>  J 

APPLICABLE  IMPLEMENTATIONS  FOR:  TABLE3  (A  SEQUENCE) 

1.  SEGMENT 

2.  VECTOR 

3.  LIST 


f  2 

LET  "VECTOR1"  BE  THE  IMPLEMENTATION  OF  TABLE3  AS  A  VECTOR. 

Finally  we  implement  Table3,  a  sequence  of  dotted  pairs,  as  a  Lisp  vector. 

6.3  Procedure  Synthesis 

The  user  now  moves  on  to  the  implementation  of  some  procedures  which  access  the  symbol  table 
data  structure.  The  first  procedure  is  to  retrieve  the  entry  associated  with  a  given  symbol.  Fig.  6-2  gives 
an  overview  of  this  implementation.  Down  the  left  side  of  this  figure  is  the  data  structure  implementation 
developed  in  the  preceding  section.  As  in  Fig.  6-1,  arrows  in  this  figure  denote  overlays  and  roles  names 
are  labelled.  In  this  figure,  however,  many  roles  are  left  out  in  order  to  make  it  more  readable.  The 
names  in  parentheses  are  the  types  of  the  roles. 

>  let  "symbol  table  retrieve"  be  a  specialization  of  retrieve, 
such  that  the  universe  Is  a  symbol  table,  and  the  key  function  Is  symbol. 


The  starting  point  for  the  program  development  is  to  specialize  the  library  input-output 
specification  Retrieve  by  constraining  the  Universe  to  be  a  symbol  table  and  the  key  function  to  be  the 
Symbol  function  defined  earlier  in  the  scenario.  In  conventional  terms,  this  would  be  called  the 
"specifications”  of  the  procedure.  It  is  important  to  note,  however,  that  in  the  plan  calculus  the  usual 
distinction  between  specifications  and  implementations  as  separate  formalisms  docs  not  exist.  What  we 
have  in  general  is  plans  at  various  levels  of  abstraction.  The  topmost  plan  often  amounts  to  what  would 
normally  called  a  specification,  and  the  bottommost  (surface)  plan  is  certainly  what  would  be  called  an 
implementation.  All  of  these  descriptions  arc  in  the  same  language,  and  there  arc  implementation 
relationships  between  the  intermediate  plans  also.  Furthermore,  in  this  framework  there  is  no  reason  to 
restrict  a  user's  starting  plan  to  being  an  input-output  specification.  The  most  natural  starting  description 
may  sometimes  be  a  multi-step  plan. 


i 
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Figure  6-2.  Implementation  of  Symbol  Table  Retrieval. 
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APPLICABLE  IMPLEMENTATIONS  FOR:  SYMBOL-TABLE-RETRIEVE  (A  RETRIEVE) 

1.  ANY-COMPOSITE 

2.  DISCRIMINATE+RETRIEVE 

f  l 


In  the  interaction  above,  the  system  has  searched  the  plan  library  for  ways  of  implementing 
Symbol-table-retrieve  (i.e.  for  overlays  with  Retrieve  as  their  right  hand  side).  In  the  current  library, 
there  are  two:  the  default  implementation  as  Any,  and  the  implementation  in  which  the  universe  is 
implemented  as  a  keyed  discrimination  (see  Fig.  6-3).  These  are  presented  as  options  to  the  user,  who 
chooses  the  second. 

The  system  at  this  point  could  have  been  more  clever  and  concluded  that  the  second  choice  was 
indicated,  since  Symbol-table  has  already  been  implemented  as  Keyed-discriminationl.  However,  this 
degree  of  automation  in  general  may  be  difficult,  particularly  in  the  presence  of  multiple  views.  In  any 
case,  once  option  two  is  chosen,  either  by  the  system  or  the  user,  the  maximal  sharing  heuristic  ensures 
that  Keyed-discriminationl  does  become  part  of  the  implementation  of  Symbol-table-retrieve. 


LET  "SYMBOL-TABLE -KEYED-DISCRIMINATE+RETRIEVE"  BE  THE  IMPLEMENTATION 
OF  SYMBOL-TABLE-RETRIEVE  AS  KEYED-DISCRIMINATE+RETRIEVE. 

ELIGIBLE  SHARING  FOR:  SYMBOL -TABLE -KEYED- DISCRIMINATE+RETRIEVE .COMPOSITE 

(A  KEYED-DISCRIMINATION) 

1.  KEYED-DISCR IMINATI0N1 

*  3 


The  system  has  created  a  specialized  version  of  the  plan  Keyed-discriminate+retrieve,  (wherein  the 
keyed  discrimination  is  Keyed-discriminationl)  which  implements  Symbol-table-retrieve  (see  Fig.  6-2). 


>  3 

APPLICABLE  IMPLEMENTATIONS  FOR: 

SYMBOL -TABLE -KEYED-DISCRIMINATE+RETRIEVE .DISCRIMINATE  (AN  8FUNCTION) 
1.  COMPOSED- 8F UNCTIONS 

*  3 

LET  "SYMBOL -TABLE -COMPOSEO-8FUNCTIONS"  BE  THE  IMPLEMENTATION  OF 

SYMBOL -TABLE -KEYED-DISCRIMINATE+RETRIEVE .DISCRIMINATE  AS  C0MP0SED-8F UNCTIONS. 

ELIGIBLE  SHARING  FOR: 

SYMBOL -TABLE -COMPOS ED- 8FUNCT IONS. COMPOSITE  (A  COMPOSED-FUNCTIONS) 
1.  HASHING1 

*  3 


Since  there  are  no  overlays  for  implementing  Symbol-tablc-keyed-discriminate+rctrievc  as  a  whole, 
the  system  proposes  applicable  overlays  for  the  roles,  beginning  with  the  Discriminate  role,  which  is 
constrained  to  be  an  instance  of  ©Function.  There  is  only  one  plan  in  the  library  for  implementing 
©Function,  i.e.  as  a  composition  of  two  other  instances  of  ©Function.  Using  the  maximal  sharing 
heuristic  again,  these  become  the  application  of  the  hash  function,  Hashl.  followed  by  fetching  from  the 
hash  table,  Tablel. 
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Figure  6*3.  Associative  Retrieval  from  a  Keyed  Discrimination. 
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>  i 

APPLICABLE  IMPLEMENTATIONS  FOR : 

SYMBOL  - TA8LE-KEYED-OISCRIMI MAT E+RETR I EVE .IF  (A  RETRIEVE) 

1.  ANY-COMPOSITE 

2.  DISCRIMINATE+PETRIEVE 

f  1 

LET  "SYMBOL -TABLE -ANY -COMPOSITE"  BE  THE  IMPLEMENTATION  OF 

SYMBOL-TABLE-KEYEO-DISCRIMINATE+RETRIEVE. IF  AS  ANY-COMPOSITE. 

Implementation  of  the  other  role  (10  of  Symbol-table-keyed-discriminatc+retrieve  is  shown  above. 
This  role  is  an  instance  of  Retrieve  applied  to  the  bucket  obtained  by  Discriminate.  As  before,  the  system 
presents  two  options  for  implementing  Retrieve.  This  time  the  user  chooses  the  first  option:  retrieval 
from  the  bucket  is  implemented  as  Any  in  which  the  criterion  is  a  composite  of  the  key  function  (Symbol) 
and  the  Input  to  Retrieve.  This  is  the  default  way  of  implementing  Retrieve.  For  example,  if  the 
Universe  set  is  implemented  as  a  list.  Retrieve  will  typically  be  implemented  as  a  car-cdr  search  loop. 

The  overlay  for  this  implementation  is  shown  in  Fig.  6-4.  The  plan  on  the  left  hand  side  is  called 
Any-compositc.  This  overlay  shows  how  an  instance  of  Retrieve  can  be  implemented  as  an  instance  of 
Any  in  which  the  Criterion  predicate  has  a  definition  of  the  following  form. 

P(x)  =  F(x,K) 

This  way  in  general  of  constructing  a  predicate,  P,  for  a  given  function,  F,  and  a  value,  K,  is 
formalized  as  the  overlay  Function+valuopredicate  (see  appendix).  In  the  implementation  of  Retrieve  as 
Any,  F  corresponds  to  the  key  function  of  Retrieve  and  K  is  the  input  key. 

Loop  Synthesis 

We  now  come  to  the  point  in  the  synthesis  where  loops  are  introduced  into  the  design.  Note  that 
the  maximal  sharing  heuristic  also  applies  to  loops,  i.e.  for  efficiency,  the  loop  implementations  of 
different  parts  of  a  program  should  be  combined  into  a  single  loop  when  possible.  In  order  to  achieve 
this  part  of  the  scenario  below,  an  additional  temporal  synthesis  module  (the  inverse  of  the  temporal 
analysis  module  discussed  in  Chapter  Five)  is  needed.1 

APPLICABLE  IMPLEMENTATIONS  FOR:  SYMBOL-TABLE-ANY-COMPOSITE . IF  (AN  ANY) 

1.  TERMINATED- ITERATIVE-SEARCH 

*  i 

To  begin.  Any  is  implemented  as  Terminatcd-iterative-search  (this  overlay  was  already  discussed  in 
Chapter  Five).  The  Universe  of  Any  is  then  implemented  as  a  loop  augmentation  which  generates  the 
inputs  to  the  second  (success)  exit  test  of  this  search  loop.  This  takes  place  in  two  steps  under  user 
guidance.  In  the  first  step,  shown  below,  the  set  is  implemented  as  a  list  (without  duplicates). 


1.  Waters  has  written  a  module  which  docs  pan  of  this  work. 
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>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR: 

SYMBOL-TABLE-ANY-COMPOSITE. IF. UNIVERSE  (A  FINITE-SET) 

1.  LIST 

2.  SEQUENCE 

3.  LABELLED-THREAD 

4.  DISCRIMINATION 


SPECIALIZATIONS  OF:  LIST 

1.  I RREOUNDANT -LIST 

»  ) 

LET  "SYMB0L-TA8LE-IRREDUNDANT-LIST"  BE  THE  IMPLEMENTATION  OF 
SYMBOL-TABLE-ANY-COMPOSITE. IF. UNIVERSE  AS  AN  IRREDUNDANT-LIST. 


As  earlier  in  this  scenario,  the  system  could  also  be  more  clever  here  and  save  the  user  some  effort 
In  particular,  the  system  should  realize  that  the  finite  sets  which  fill  the  Symbol-table-any- 
composite.If.Universe  role  are  the  same  as  the  buckets  of  Tablel,  which  were  implemented  earlier  as 
irrcdundant  lists.  Finally,  the  irredundant  lists  of  entries  are  implemented  as  the  standard  Lisp  car,  cdr 
and  null  loop,  as  shown  below. 


>  i 

APPLICABLE  IMPLEMENTATIONS  FOR: 

SYMBOL-TABLE-IRREDUNDANT-LIST  (AN  IRREDUNDANT-LIST) 

1.  UPPER-SEGMENT 

2.  DOTTED-PAIR 

3.  LIST-GENERATION 


EXTENSIONS  OF:  LIST-GENERATION 

1.  TRUNCATED-LIST-GENERATION 

?  ) 

SPECIALIZATIONS  OF:  TRUNCATED-LIST-GENERATION 
1.  CAR+CDR+NULL 

'  i 


Code  Generation 


The  final  phase  of  top-down  synthesis  is  code  generation.  The  user  has  guided  the  implementation 
of  all  parts  of  the  program  down  to  the  level  of  input-output  and  test  specifications  involving  the 
primitive  functions  and  relations  of  Lisp.  All  that  remains  now  to  obtain  a  complete  surface  plan  is  to 
gather  up  all  the  control  flow  and  data  flow  constraints  between  terminal  nodes  of  Fig.  6-2  into  a  single 
non-hierarchical  plan  (and  also  to  add  additional,  arbitrarily  chosen,  control  flow  arcs  as  necessary  to 
totally  order  any  otherwise  unordered  steps).  The  resulting  surface  plan  is  essentially  the  same  as  the 
surface  plan  obtained  in  the  analysis  of  lookup  in  Chapter  Five.  This  surface  plan  is  then  turned  over  to  a 
code  generator,  which  implements  the  data  and  control  flow  using  the  available  connective  primitives  in 
the  programming  language,  as  shown  below. 
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>  show  code  for  symbol -tabl8-,,etr1»v» 

(DEFINE  SYMBOL -TABLE -RETRIEVE 
(LAMBDA  (TABLE  INPUT) 

(PROG  (BUCKET  OUTPUT) 

(SETQ  BUCKET  (ARRAYFETCH  TABLE  (HASH  INPUT))) 
LP  (COND  ((NULL  8UCKET)(RETURN  NIL))) 

(SETQ  OUTPUT  (CAR  BUCKET)) 

(COND  ((EQ  (CAR  OUTPUT)  INPUT) 

(RETURN  OUTPUT))) 

(SETQ  BUCKET  (CDR  BUCKET)) 

(GO  LP)))) 


A  code  generator  for  Lisp  has  been  implemented  by  Waters  [74].  Note  that  at  the  end  of  this  entire 
process,  we  get  essentially  the  same  structure  as  in  Chapter  Five,  namely  code  for  the  program  (perhaps 
with  some  minor  syntactic  variations  due  to  the  stylistic  biases  of  the  code  generator),  together  with  a 
complete  hierarchical  decomposition  of  the  design  in  terms  of  plans  in  the  library. 


Synthesis  of  Symbol  Table  Addition 

This  section  shows  the  synthesis  of  a  procedure  to  add  entries  to  the  symbol  table.  Two  new  points 
are  introduced  in  this  example.  First,  the  plans  in  this  example  involve  side  effects.  Second,  the  user 
intervenes  at  a  key  point  in  the  development  in  order  to  suggest  a  rcanalysis  which  leads  the  system  to  the 
desired  program.  An  overview  of  the  complete  implementation  structure  is  shown  in  Fig.  6-5. 

>  let  "symbol  table  add"  be  a  specialization  of  set  add  by  side  effect 
such  that  the  old  set  Is  a  symbol  table,  and  the  Input  does  not  belong  to 
the  old  set. 

The  starting  point  for  this  synthesis  is  a  specialization  of  the  input-output  specification  Set-add,  in 
which  the  old  set  is  a  symbol  table.  The  first  additional  constraint  above  specializes  Set-add  to  the  side 
effect  version,  # Set-add,1  in  which  the  new  set  has  the  same  identity  as  the  old  set  (but  different 
members).  The  role  names  Old  and  New  in  this  case  refer  to  the  different  states  of  the  same  Set  before 
and  after  the  side  effect  operation,  rather  than  to  different  sets.2  The  user  has  also  specified  as  a 
precondition  that  the  entry  to  be  added  is  not  already  in  the  table.  This  is  another  standard  specialization 
of  Set-add,  called  Set-add-onc,  which  has  simpler  implementations  in  which  there  is  no  need  to  check  for 
duplicates. 


1.  The  character  is  intended  lo  be  read  as  "impure".  Thus  #Sei-add  is  "impure  set  add"  or  "set  add  by  side  effect". 
1  The  formal  representation  of  side  effects  will  be  specified  in  more  detail  in  Chapters  Eight 
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Figure  6*5.  Implementation  of  Addition  to  Symbol  Table. 
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>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR:  ASYMBOL -TABLE -ADD  (A  SET-AOO-ONE) 

1 •  PUSH 

2!  INTERNAL-THREAQ-ADD 
3.  DISCRIMINATE+ACTK  N+UPDATE 

f  1 

LET  "ASYMBOL-TABLE-DISCRIM1NATE+ACTION+UPDATE"  BE  THE  IMPLEMENTATION  OF 
AS YMBOL- TABLE -ADO  AS  DISCRIMINATE+ACTION+UPDATE ,  SUCH  THAT 
ASYMBOL -TABLE -DISCRIMINATE+ACTION+UPDATE .ACTION  IS  SET  ADDITION. 

AND  AS YMBOL -TABLE -DISCRIMINATE+ACTION+UPDATE .UPDATE  IS  BY  SIDE  EFFECT. 


The  system  begins  by  retrieving  three  possible  implementations  for  #  Symbol-table-add.  The  first 
two  arc  implementations  of  Set-add  for  sets  implemented  as  lists  or  labelled  threads;  the  third  overlay 
(shown  in  Fig.  6-6)  is  the  implementation  of  Old+input+output-set  (of  which  Set-add  is  a  specialization) 
for  sets  implemented  as  discriminations.  The  user  chooses  the  third  option,1  and  the  system  responds  as 
usual  by  specializing  the  left  hand  side  plan  appropriately. 

Notice  that  the  overlay  in  Fig.  6-6  is  between  two  plans  in  which  no  commitment  has  yet  been  made 
as  to  whether  or  not  side  effects  are  involved.  One  of  the  pre-computed  properties  of  this  overlay  is  that  if 
the  right  hand  side  is  specialized  to  be  by  side  effect  (i.e.  *  Set-add  or  # Set-remove),  then  the  Update 
step  on  the  left  hand  side  is  also  by  side  effect  (i.e.  #Newvalue),  and  vice  versa. 

Since  there  are  no  overlays  for  #SymboI-tablc-discriminatc+action+update  as  a  whole,  the  system 
looks  for  implementations  of  the  roles  separately.  The  Discriminate  role  is  an  instance  of  ©Function,  in 
which  Discrimination!  is  the  function  applied  (Op).  The  further  implementation  of  this  role  is  simply  a 
two  level  composition  of  instances  of  ©Function  which  mirrors  the  decomposition  of  Discrimination! 
into  Symbol,  Hash!  and  Table!.  This  is  shown  in  Fig.  6-5,  but  omitted  from  the  scenario  transcript  here. 


>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR: 

ASYMBOL-TABLE -DISCRIMINATE+ACTION+UPDATE. ACTION  (A  SET-ADD-ONE) 

1.  PUSH 

2.  INTERNAL-THREAD-ADD 

3.  DISCRIMINATE+ACTION+UPDATE 

1  1 

LET  "SYMBOL-TABLE-PUSH"  BE  THE  IMPLEMENTATION  OF 
ASYMBOL-TABLE -DISCRIMINATE+ACTION+UPDATE .ACTION  AS  PUSH. 


The  user  chooses  to  implement  Set-add-one  operations  on  the  buckets  by  pushing  new  elements  on 
the  front  of  the  lists. 


I.  As  discussed  earlier,  if  (he  system  assumes  the  same  set  is  not  being  implemented  two  different  ways,  it  could  chcosc  this  option 
on  its  own  initialise.  However,  some  clever  implementations  actually  do  involve  implementing  the  same  abstract  data  structure 
simultaneously  two  different  ways. 


/ 


CHAPTER  SIX 


Figure  6-6.  Adding  and  Removing  Members  from  a  Discrimination. 
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>  i 

APPLICABLE  IMPLEMENTATIONS  FOR: 

#S YMBOL-T ABLE -OISCRIMINATE+ACTION+UPDATE .UPDATE  (A  RNEWVALUE ) 
1.  NEWVALUE-COMPOSITE 

»  i 

LET  "NEWVALUE -COMPOSITE'  BE  THE  IMPLEMENTATION  OF 
#SYMBOL-TABLE-DISCRIMINATE+ACTION+UPDATE .UPDATE  AS  NEWVALUE-COMPOSITE 
BY  SIDE  EFFECT. 


As  discussed  in  Chapter  Four,  Newvalue  operations  on  a  function  implemented  as  a  composition 
can  be  implemented  by  Newvalue  operations  on  the  second  component  only.  Furthermore,  a  property  of 
this  implementation  is  that  if  the  operation  on  the  second  component  is  by  side  effect,  then  in  effect  the 
composed  function  has  been  modified  by  side  effect  In  this  case,  #Newvalue  operations  on 
Discrimination!  are  implemented  as  ^Newvalue  operations  on  Functionl.  Similarly  (see  Fig.  6-5,  but 
not  shown  here),  *  Newvalue  operations  on  Functionl  are  implemented  as  #  Newvalue  operations  on 
Tablel.  This  completes  implementation  of  all  roles  of  #Symbol-table-discriminate+action+update. 

Prompted  by  the  user,  the  system  continues  to  suggest  overlays  for  implementing  the  parts  of  the 
design  which  are  not  yet  down  to  the  level  of  Lisp  primitives.  The  two  simple  steps  shown  below  are:  (i) 
to  implement  Symbol-table-push  as  cons  (compatible  with  the  implementation  of  the  buckets  of  the  table 
as  Lisp  lists),  and  (ii)  to  implement  Term  applied  to  Tablel  as  arrayfetch  (compatible  with  the 
implementation  of  Tablel  as  Vectorl.)1 


>  ) 

APPLICABLE  OVERLAYS  FOR:  SYMBOL-TABLE-PUSH  (PUSH) 

1.  BUMP+UPDATE 

2.  CONS 

r  i 


> ) 

APPLICABLE  OVERLAYS  FOR:  SYMBOL-TABLE-COMPOSED-BFUNCTIONS.TWO  (TERM) 
1.  FETCH 

■»  i 


Other  simple  steps,  omitted  here,  are  the  implementation  of  the  application  of  Symbol  as  car,  and 
the  application  of  Hashl  as  a  procedure  call.  This  leaves  only  #  Newvalue  applied  to  Tablel  (see  Fig.  6-5) 
to  be  implemented  further. 


>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR: 

#S YMBOL-T ABLE -NEWVALUE -TWO- COMPOSITE .ACTION  (A  fNEWVALUE ) 
1.  NEWVALUE-COMPOSITE 

7  a® 


10  APPLICABLE  OVERLAYS. 


1.  This  is  skipping  the  intermediate  steps  of  Tab!e2  and  Table  t,  as  discussed  earlier. 
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Unfortunately,  the  only  implementation  in  the  current  library  for  aNewvalue1  is  for  a  function 
implemented  as  a  composition  of  two  functions,  which  is  not  what  we  want  for  Tablcl.  At  this  point  the 
simple  refinement  strategy  used  by  the  system  thus  far  is  stymied.  The  problem  is  that  in  order  to 
implement  tfNewvalue  as  the  simpler  #  Newarg  (which  then  becomes  arraystore  for  Lisp  vectors),  the 
system  must  recognize  that  the  function  involved  is  one-to-one  (a  Bijcction)  and  that  the  argument  which 
maps  to  the  old  value  has  already  been  computed.  The  plan  which  the  system  recognizes  is  called 
@F u  net  ion+new  value  and  is  shown  on  the  right  hand  side  of  Fig.  6-7. 

The  basic  idea  of  the  overlay  in  Fig.  6-7  is  that  in  the  special  case  of  one-to-one  functions,  an 
instance  of  ©Function  followed  by  Newvalue,  as  in  the  Discriminate+action+update  plan,  can  be 
implemented  simply  by  an  instance  of  Newarg.  In  other  words,  if  you  know  that  there  is  only  one 
domain  element  which  maps  to  a  given  range  element,  then  updating  all  domain  elements  which  map  to 
that  range  element  (i.e.  Newvalue)  degenerates  into  changing  the  value  associated  with  that  one  domain 
element  (i.e.  Newarg).  Furthermore,  in  terms  of  side  effects,  an  impure  Update  operation  (#Newvalue) 
in  ©Function+newvalue  corresponds  to  #  Newarg. 

>  recognize  ftfunctlon+neevalue. 

LET  "NSYMBOL - T ABLE -8FUNCT ION+NEWVALUE *  BE  A  SPECIALIZATION  OF 

8FUNCT ION+NEWVALUE  SUCH  THAT 

#S YMBOL -TABLE -8FUNCT ION+NEWVALUE. ACT ION. 0P*T ABLE 1  . 

The  user  guides  the  system  at  this  point  by  advising  it  to  try  to  recognize  an  instance  of  the  plan 
©Function+newvalue  somewhere  in  the  current  design.  Given  the  focus  of  trying  to  recognize  only  one 
particular  plan,  the  system  succeeds  in  noticing  that  Symbol-table-composed-@functions.Two  (see 
Fig.  6-5)  together  with  the  #Symbol-table-newvalue-two-composite.Action  satisfy  the  constraints  of 
@Function+newvalue.2  What  has  happened  here  is  that  parts  of  two  different  branches  of  the  tree  have 
been  grouped  together  to  recognize  a  plan  which  has  a  known  implementation.  This  is  a  novel  feature  of 
this  synthesis  scenario  as  compared  to  the  standard  top-down  refinement  approach. 

>  3 

APPLICABLE  IMPLEMENTATIONS  FOR: 

#SYM80L- TABLE-BFUNCT ION+NEWVALUE  (A  8FUNCT ION+NEWVALUE) 

1.  NEWARG-BI JECTION 

*  3 

LET  ’NSYMBOL -TABLE -NEWAR6-B I JECTION’  BE  THE  IMPLEMENTATION  OF 

#SYMBOl- TABLE-BFUNCT ION+NEWVALUE  AS  NEWAR6-BIJECTI0N. 

Now  the  overlay  can  be  applied  which  implements  #Newvalue  as  a  Newarg,  or  in  the  case  of  a  sequence, 
#  New  term,  and  finally,  as  #  Store. 


].  Recall  that  Newvalue  is  the  specification  for  updating  a  (Unction  such  that  all  arguments  that  used  to  map  to  a  given  value,  map 
to  a  new  given  value. 

2.  Table  1  is  an  irredundent  sequence,  which  means  it  is  a  ooe-to-one  function. 
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Figure  6*7.  Updating  a  Rijcction. 
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>  i 

APPLICABLE  IMPLEMENTATIONS  FOR:  #SYMBOL-TABLE-NEWARG-BI JECTION  (A  0NEWTERM) 
1.  #STORE 
7  i 


Code  generation  follows  in  a  similar  fashion  to  before. 


>  show  code  for  fsymbol -table-add 
(DEFINE  SYMBOL -TABLE -ADD 

(LAMBDA  (TABLE  INPUT)  ;MODIFIES  TABLE. 

(PROG  (INDEX) 

(SETQ  INDEX  (HASH  (CAR  INPUT))) 

(ARRAYSTORE  TABLE  INDEX 

(CONS  (ARRAYFETCH  TABLE  INDEX) 
INPUT))))) 


Synthesis  of  Associative  Deletion 


The  last  procedure  to  be  synthesized  is  for  associative  deletion  of  entries  in  the  symbol  table.  This 
procedure  and  its  development  share  many  features  with  the  retrieval  and  addition  procedures,  which 
have  already  been  presented  in  detail.  This  part  of  the  scenario  will  therefore  be  brief  and  will  for  the 
most  part  rely  on  Fig.  6-8  rather  than  showing  all  of  the  system-user  interactions,  as  in  the  preceding 
sections. 


>  let  'symbol  table  expunge'  be  a  specialization  of  expunge  by  side  effect  such 
that  the  old  set  Is  a  symbol  table,  the  key  function  is  symbol, 
and  there  exists  a  unique  *x’  such  that  x  belongs  to  the  old  set 
and  the  key  function  applied  to  x  equals  the  Input. 

These  are  the  starting  specifications.  Expunge  is  a  standard  input-output  specification  in  the  library 
for  deleting  from  a  set  on  the  basis  of  a  given  key  value.  The  deletion  here  is  by  side  effect,  and  there  is 
an  additional  precondition  specified,  namely  that  there  is  exactly  one  entry  in  the  table  with  the  given 
key.  This  precondition  specializes  Expunge  to  Expunge-one,  a  standard  specialization  of  Expunge  in  the 
library. 


>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR:  fSYMBOL -TABLE -EXPUNGE  (AN  EXPUNGE-ONE) 

1.  RESTRICT-COMPOSITE 

2.  KEYED-D1SCRIMINATE+EXPUNGE+UPDATE 

11 

LET  "NSYMBOL-TABLE-KEYEO-DISCRIMINATE+EXPUNGE+UPDATE"  BE  THE  IMPLEMENTATION 

OF  PS YMBOL -TABL E -EX PUNGE  AS  KEYED-DISCRIMINATE+EXPUNGE+UPDATE . 

For  sets  implemented  as  keyed  discriminations.  Expunge  is  implemented  by  the  three  step  plan 
Discriminate+expungc+update,  shown  in  Fig.  6-9,  which  is  similar  to  Discriminatc+action+updatc  in  the 
implementation  of  symbol-table-add.  Like  Discriminatc+action+updatc  the  pre-compilcd  side  effect 
analysis  of  this  plan  says  that  the  side  effect  implementation  is  achieve  by  specializing  the  Update  step  to 
#  New  value.  Part  of  the  cleverness  in  this  synthesis  example  involves  avoiding  the  Update  step  entirely 
by  performing  the  Action  by  side  effect  instead. 
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Figure  6*8.  Implementation  of  Associative  Deletion  from  Symbol  Table. 
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Figure  6*9,  Associative  Deletion  from  Keyed  Discrimination. 
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The  first  step  in  Discriminate+expunge+update,  Discriminate,  is  an  instance  of  ©Function  which 
computes  the  appropriate  bucket  from  the  given  key.  The  implementation  of  this  step  uses  the  plan 
Symbol-table-composed-@functions,  which  was  developed  in  the  synthesis  of  symbol -table -retrieve 
(see  Fig.  6-8). 

>  i 

APPI  TTARi  F  TMPI  FMFUTATTDhK  FDR* 

ASYMBOL -TABLE -KEYED-DISCRIMINATE+EXPUNGE+UPDATE. ACT ION  (AN  EXPUNGE-ONE) 

1.  RESTRICT-COMPOSITE 

2.  KEYED-OISCRIMINATE+EXPUNGE+UPDATE 

1  1 

LET  "SYMBOL -TABLE -RESTRICT -COMPOSITE"  BE  THE  IMPLEMENTATION  OF 

#SYM80L-T ABLE- KEYED-D I  SCRIM I NATE +EXPUNGE+UPDATE. ACTION  AS  RESTRICT-COMPOSITE. 

The  Expunge-one  action  on  the  buckets  is  implemented  in  the  default  way  using  Restrict,  in  which 
the  criterion  is  a  composition  of  the  Symbol  function  and  #Symbol-table-cxpunge.Key.  This  overlay  is 
shown  in  Fig.  6-10.  It  is  similar  to  the  implementation  of  Retrieve  as  Any-composite  in 

symbol-table -retrieve.  Furthermore,  it  is  a  property  of  this  overlay  that  if  the  right  hand  side  is 
specialized  to  Expunge-one,  then  the  Action  on  the  left  hand  side  is  correspondingly  specialized  to 
Rcstrict-one,  in  which  there  is  expected  to  be  only  one  member  of  the  Universe  set  which  satisfies  the 
given  Criterion. 

>  ) 

APPLICABLE  IMPLEMENTATIONS  FOR: 

SYMBOL-TABLE-RESTRICT-COMPOSITE. ACTION  (A  RESTRICT-ONE) 

1.  ITERATIVE-FILTERING 

2.  RTAIL-f INTERNAL 

»  2 

LET  "SYMBOL -TAB LE-0TA I L+INTERNAL"  BE  THE  IMPLEMENTATION  OF 

SYMBOL-TABLE-RESTRICT-COMPOSITE. ACTION  AS  8T A I L+INTERNAL. 

Restrict  can  be  implemented  either  as  a  filtering  loop,  or  as  the  plan  @Tail+intemal,  shown  in 
Fig.  6-11.  This  plan  removes  a  member  from  a  set  implemented  as  an  irredundant  list 

Removing  a  member  from  a  set  implemented  as  an  irredundant  list  breaks  down  into  two  cases:  if  it 
happens  that  the  member  to  be  removed  is  the  head  of  the  list,  then  removal  is  achieved  simply  by  a 
taking  the  tail  of  the  list;  otherwise,  viewing  the  list  as  a  labelled  thread,  the  internal  node  of  the  spine 
which  is  labelled  with  the  given  member  must  be  found  and  removed.  These  two  cases  will  eventually 
manifest  themselves  in  the  code  as  follows: 
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Figure  6-12.  internal  Labelled  'Hi  read  Find  and  Remove. 
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(DEFINE  SYMBOL-TABLE -EXPUNGE 
(LAMBDA  (...  INPUT) 

(PROG  (...  BUCKET  PREVIOUS) 

(SETQ  PREVIOUS  ...) 

(COND  ( ( EQ  (CAAR  PREVIOUS)  INPUT) 

(...  (COR  PREVIOUS)) 

(RETURN  NIL))) 

LP  ... 

(COND  ((EQ  (CAAR  BUCKET)  INPUT) 

( RPLACD  PREVIOUS  (CDR  BUCKET)) 
(RETURN  NIL))) 

(GO  LP)))) 


Let  us  first  consider  the  overlay  @Tail+intcmal>restrict  in  Fig.  6-11,  which  formalizes  the 
breakdown  into  two  cases  described  above.  On  the  right  hand  side  of  this  overlay  we  have  Restrict-one, 
which  specifics  the  removal  of  the  (unique)  member  of  a  set  which  docs  not  satisfy  a  given  criterion.  The 
top  level  structure  of  the  plan  on  the  left,  which  implements  these  specifications,  is  a  conditional  (Cond). 
The  Input  to  the  test  of  this  conditional  is  the  head  of  the  irredundant  list  which  implements  the  Old  set; 
the  criterion  is  the  complement  of  the  criterion  of  Restrict-one.  The  output  of  this  conditional 
(F.nd.output)  is  the  irredundant  list  which  implements  the  New  set.  In  the  Succeed  case  (i.e.  when  the 
head  of  the  input  list  satisfies  the  given  criterion),  this  output  is  the  resulting  of  taking  the  tail  of  the  input 
list.  In  the  Fail  case,  the  new  list  is  computed  by  Intcmal-labcllcd-thread-find+remove. 

Intcrnal-labclled-thrcad-find+remove,  shown  in  Fig.  6-12,  is  an  extension  of  !nternal-thread-find+ 
remove.  In  this  plan,  the  old  and  new  lists  are  thought  of  as  labelled  threads.  Intemal-labelled-thread- 
find+remove  removes  an  internal  node  from  the  spine  of  a  labelled  thread  (Old),  the  label  of  which 
satisfies  a  given  predicate,  resulting  in  a  (New)  labelled  thread.  As  used  in  @Tail+intemal,  the  criterion 
applied  by  Find  to  each  node  in  the  spine  of  the  labelled  list  is  composed  from  Update.If.Criterion  and 
the  label  function  of  the  list  viewed  as  a  labelled  thread,  according  to  the  overlay  Predicatc+function> 
predicate,  given  in  the  appendix.  The  basic  idea  of  this  construction  is  to  test  the  label  of  each  node, 
rather  than  the  node  itself.  Thus  for  example,  if  the  label  function  is  Car  (as  in  the  case  of  Lisp  lists),  and 
Update.If.Criterion  is  P,  then  the  criterion  of  the  Find  step  is  Q  defined  as  follows: 


Q(x)  =  P(Car(x)) 


APPLICABLE  IMPLEMENTATIONS  FOR: 

SYMBOL -TABLE-9TAIL+INTERNAL. INTERNAL. FIND  (AN  INTERNAL-THREAD-FIND) 
1.  TRAIL  I NG-GENERAT ION+SE ARCH 

»  i 


The  Find  role  of  Intcmal-labcllcd-thrcad-find+remove,  which  is  an  instance  of  Intcmal-thread-find, 
is  implemented  as  a  Trailing-generation+search  loop,  as  shown  in  Fig.  6-13.  The  Universe  of  Intemal- 
thread-find  is  the  thread  generated  by  the  trailing  generation,  and  the  two  outputs  of  the  loop  correspond 
to  the  two  outputs  of  Intcrnal-thrcad-fmd.  This  plan  will  eventually  appear  in  the  code  as  follows,  in 
which  the  function  being  applied  by  the  action  is  Cdr,  the  Current  object  is  in  bucket  and  the  Previous 
object  in  previous. 
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(PROG  (...  BUCKET  PREVIOUS) 

(SETO  PREVIOUS  ...) 

LP  (SETO  BUCKET  (CDR  PREVIOUS)) 
(COND  ((...BUCKET...) 

...PREVIOUS... BUCKET... 
(RETURN  NIL))) 

(SETO  PREVIOUS  BUCKET) 

(GO  LP)) 


The  system  then  proposes  to  implement  Internal-thread-remove  by  splicing  out,  but  the  user 
intervenes  to  suggest  a  rcanalysis. 


APPLICABLE  IMPLEMENTATIONS  FOR:  SYMBOL-TABLE-0TAIL+INTERNAL . INTERNAL. REMOVE 

(AN  INTERNAL-THREAD-REMOVE) 

1.  SPLICEOUT 

?  no 


>  recognize  factlon+update. 

LET  0SYMBOL-TABLE-ACT ION+UPDATE  BE  A  SPECIALIZATION  OF  (KACTION+UPDATE 
SUCH  THAT  #SYMBOL-TAbLE -ACTION+UPDATE . UPDATE .OLD= FUNCTION 1  . 

In  contrast  to  symbol-table-add,  where  advice  from  the  user  was  crucial  to  completing  the 
synthesis,  this  intervention  is  merely  to  cause  the  system  to  come  out  with  a  more  efficient  program.  In 
particular  we  want  the  system  to  realize  that,  if  Internal-thrcad-remove  is  implemented  by  side  effect, 
then  when  the  member  of  the  bucket  to  be  deleted  is  not  the  Head,  the  operation  to  update  the  table  is 
not  necessary.  This  piece  of  implementation  knowledge  is  represented  in  the  library'  by  the  overlay 
#01d+input+new>action+update.  which  will  be  discussed  further  in  Chapter  Eight.  The  basic  idea  of  this 
overlay,  however,  is  that  in  general,  modifying  a  range  element  amounts  to  modifying  the  function.  In 
order  to  apply  this  overlay,  however,  the  system  must  first  group  together  parts  of  plans  on  different 
branches  of  the  tree  (see  Fig.  6-8),  as  was  the  case  in  the  synthesis  of  symbol-table-add. 

Thus  the  system  implements  the  lntemal.Rcmove  step  of  Symbol-table-(aTail+internal  as  # Internal- 
thrcad-remove,  which  is  further  implemented  as  ^Spliccout,  as  shown  in  Fig.  6-14. 

Spliccout  has  four  roles:  Old  and  New,  which  are  iterators  with  the  same  seed:  Bump,  which  is  an 
instance  of  Apply;  and  Splice,  which  is  an  instance  of  Newarg.  The  purpose  of  Bump  is  to  get  the 
successor  of  the  node  to  be  removed,  which  becomes  the  Input  of  Splice.  The  Arg  of  Splice  is  the 
predecessor  of  the  Input  of  Bump  (which  typically  comes  from  an  instance  of  Intemal-thrcad-find).  The 
Op  of  the  Old  iterator  (c.g.  Cdr  for  Lisp  lists)  is  the  Op  input  to  both  Bump  and  Splice;  the  Op  of  the  new 
iterator  is  the  output  of  Splice.  This  plan  will  eventually  emerge  as  the  following  code. 

(RPLACD  PREVIOUS  (CDR  BUCKET)) 

Spliceout  implements  Intcrnal-thread-remove  as  described  by  the  overlay  Spliccout>rcmove,  shown 
in  Fig.  6-14.  The  old  iterator  implements  the  old  thread,  and  the  new  iterator  implements  the  new  thread. 
The  node  being  deleted  is  the  Input  of  Bump.  Notice  that  the  Arg  input  to  Splice  in  the  Spliccout  plan 
(the  predecessor  of  the  node  deleted)  has  no  corresponding  object  on  the  right  hand  side  of  the  overlay. 
This  means  that  as  far  as  this  overlay  is  concerned,  some  other  part  of  the  program  surrounding  an 


XwYfttoal  --tWeaA-ftVAw/e. 
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Figure  6-14.  Removing  from  a  Thread  by  Splicing  Out 
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instance  of  the  left  hand  side  (e.g.  the  Intemai-thread-fmd)  must  provide  an  Arg  input  to  Splice  which 
satisfies  the  successor  constraint.  In  other  words  this  is  an  implementation  of  lntcmal-thread-remove  for 
the  case  when  we  already  know  the  location  of  the  node  to  be  removed. 

By  the  further  rearrangement  and  straightforward  implementation  steps,  we  arrive  finally  at  a 
surface  plan  which  can  then  be  turned  over  to  the  code  generator.  The  resulting  code  is  essentially  the 
same  as  in  the  scenario  of  Chapter  Two. 


>  show  code  for  fsymbol -table-expunge. 

(DEFINE  SYMBOL -TABLE -EXPUNGE 
(LAMBDA  (TABLE  INPUT) 

(PROG  (INDEX  BUCKET  PREVIOUS) 

(SETQ  INDEX  (HASH  INPUT)) 

(SETQ  PREVIOUS  (ARRAYFETCH  TABLE  INDEX)) 

(COND  ((EQ  (CAAR  PREVIOUS)  INPUT) 

(ARRAYSTORE  TABLE  INDEX  (CDR  PREVIOUS)) 
(RETURN  NIL))) 

LP  (SETQ  BUCKET  (CDR  PREVIOUS)) 

(COND  ((EQ  (CAAR  BUCKET)  INPUT) 

(RPLACD  PREVIOUS  (CDR  BUCKET)) 

(RETURN  NIL))) 

(SETQ  PREVIOUS  BUCKET) 

(GO  LP)))) 
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CHAPTER  SEVEN 
VERIFICATION  BY  INSPECTION 


This  brief  chapter  outlines  the  applicability  of  inspection  methods  and  the  plan  library  to  program 
verification.  Program  verification  has  at  least  two  main  aspects: 

(i)  increasing  confidence  in  the  correctness  of  a  program, 

(ii)  detecting  potential  errors. 

Verifying  Overlays 

The  use  of  the  plan  library  can  increase  confidence  in  the  correctness  of  a  program  by  virtue  of  the 
fact  that  overlays  in  the  library  can  be  pre- verified.  If  a  program  is  constructed  entirely  out  of  plans  and 
overlays  from  the  library,  then  it  is  guaranteed  to  be  correct  (in  the  sense  of  there  being  no 
implementation  errors  —  the  program  may  still  not  do  what  the  programmer  wanted  in  the  ultimate 
sense).  To  the  extent  that  parts  of  a  program  are  constructed  using  the  library,  confidence  in  the 
correctness  of  the  program  is  increased. 

A  completely  formal  statement  of  the  correctness  conditions  on  overlays  depends  on  the  logical 
foundations  of  the  plan  calculus  developed  in  Chapter  Eight  The  basic  idea,  however,  is  to  verify  that 
the  function  defined  by  an  overlay  and  its  inverse  mapping  are  both  total,  i.e.  they  are  defined  on  all 
instances  of  the  left  and  right  hand  hand  side  plans,  respectively.  Practically  speaking,  the  effect  of  this 
definition  of  correctness  is  to  force  all  of  the  conditions  required  for  the  correct  use  of  an  overlay  to  be 
explicitly  stated  in  the  constraints  of  the  plans  on  both  sides. 

Note  that  techniques  for  automatically  verifying  the  correctness  of  overlays  are  not  the  concern  of 
this  report.  The  important  point  established  here  is  only  that  there  exists  for  the  plan  calculus  a  formally 
definable  and  usable  notion  of  correctness,  which  has  not  been  the  case  for  other  formalisms  used  to 
represent  the  same  knowledge.  Given  the  formal  definitions  in  Chapter  Eight,  it  is  possible  to  verify 
overlays  to  whatever  degree  of  rigor  is  warranted,  up  to  and  including  a  step-by-step  formal  proof  in  first 
order  logic  (which  might  be  mechanically  produced).  Note  however  that  these  proofs  can  be  quite 
difficult  and  idiosyncratic,  depending  as  they  do  on  the  mathematical  properties  of  the  various 
programming  domains  involved;  but  this  is  as  one  would  expect  The  thrust  of  using  inspection  methods 
is  to  take  advantage  of  this  effort  by  rc-using  these  proofs  as  lemmas. 

Near-Miss  Recognition 

An  inspection  method  for  error  detection  is  nearmiss  recognition.  In  ncar-miss  recognition,  most 
but  not  all  of  the  constraints  of  a  plan  arc  satisfied.  If  part  of  a  user's  design  almost  matches  a  plan  in  the 
library,  the  discrepancy  between  the  two  descriptions  can  be  brought  to  the  user’s  attention  as  a  potential 
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error.  This  method  of  error  detection  makes  use  of  the  correct  plans  in  the  library  to  detect  errors,  rather 
than  explicitly  adding  a  taxonomy  of  errors  to  the  "grammar"  as  in  Ruth  [59]. 

L.ike  all  inspection  methods,  error  detection  by  inspection  is  not  as  powerful  as  more  general 
methods.  However,  it  has  the  advantage  that  potential  errors  arc  characterized  in  terms  which  are  closer 
to  the  engineering  vocabulary  of  the  user’s  design.  The  remainder  of  this  chapter  gives  an  example  in 
detail.  The  method  described  in  this  example  has  not  yet  been  implemented,  however  the 
implementation  of  an  algorithm  for  near-miss  pattern  matching  using  the  plan  library  is  currently  in 
progress  by  Brotsky  [8], 

In  the  scenario  of  Chapter  Two,  the  user  typed  in  the  following  code  for  finding  an  element  in  a  list 
satisfying  a  given  criterion,  and  splicing  it  out 

(DEFINE  BUCKET -DELETE 

(LAMBDA  (BUCKET  INPUT)  ;MODIFIES  BUCKET. 

(PROG  (P  0) 

(SETQ  P  BUCKET) 

LP  (COND  ((EQUAL  (CAAR  P)  INPUT) 

(RPLACD  Q  P)  -.SPLICE  OUT. 

(RETURN  BUCKET))) 

(SETQ  Q  P) 

(SETQ  P  (CDR  P)) 

(60  LP)))) 

There  were  two  errors  detected  in  this  code:  one  in  the  loop  that  finds  the  element,  and  one  in  the 
splicing  out.  This  section  discusses  only  the  detection  of  the  first  error. 

The  first  step  in  detecting  an  error  is  to  translate  the  code  above  into  the  plan  calculus  as  discussed 
in  Chapters  Four  and  Five.  The  surface  plan  for  the  loop  part  of  bucket-oelete  (not  including  the  splice 
out  after  the  loop)  is  shown  on  the  left  of  Fig.  7-1.  To  make  this  example  easier  to  follow,  the  surface  plan 
shown  in  the  figure  has  been  simplified  by  omitting  the  control  flow  arcs  (since  the  important  recognition 
in  this  example  depends  on  the  data  flow),  and  by  assuming  that  the  code  (equal  (caar  p)  input)  has 
already  been  analyzed  as  the  testing  of  p  by  a  composite  predicate  made  up  out  of  the  Eq  relation,  the 
Caar  function  and  input.1 

The  next  steps  arc  to  recognize  Trailing-search  and  Iterative-generation  in  the  surface  plan  for 
bucket-delete.  Fig.  7*1  illustrates  the  recognition  of  Trailing-search.  Trailing-search,  shown  on  the  right 
hand  side  of  the  figure,  is  a  loop  plan  with  four  roles:  Exit,  Tail,  Current  and  Previous.  As  in  all  loop 
plans,2  the  recursively  defined  role  is  called  Tail.  The  Exit  role  is  a  conditional  plan  which  groups 
together  the  exit  test  (Exit-If)  of  the  loop  and  the  join  (ExitEnd)  "on  the  way  up".  If  the  exit  test 
succeeds,  the  loop  terminates  (and  the  input  to  the  test  is  available  through  the  join  as  an  output  of  the 
loop);  otherwise  it  continues.  The  Current  and  Previous  roles  are  what  make  this  plan  a  trailing  loop. 
The  Current  object  on  each  iteration  is  the  same  as  the  Previous  object  on  the  next  iteration 
(Tail.Previous).  The  Current  object  in  a  trailing  search  loop  is  the  input  to  the  test;  and  both  the  Current 
and  the  Previous  object  arc  available  through  the  join  (ExitEnd)  as  outputs  of  the  loop.  ExitEnd  is  an 


1.  Using  the  overlays  Binrcl  +  two>prcdicate  and  Predicate  +  function>prcdicatc  (see  appendix). 
1  A  detailed  taxonomy  of  loop  plans  is  given  in  Chapter  Nine. 
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Figure  7*1.  Recognizing  Trailing  Search  in  liucket-Dcletc. 
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instance  of  Join-two-outputs,  an  extension  of  Join-outputs  (see  Chapter  Eight)  in  which  two  outputs  are 
joined. 

The  surface  plan  for  bucket-delete,  Delete-loop,  can  be  analyzed  as  Trailing-search  by  identifying 
Dclete-loop.lf  with  Trailing-scarch.Exit.lf  (in  which  case  p  in  the  code  holds  to  the  Current  object),  and 
identifying  Dclcte-loop.End  with  Trailing-search.Exit.End  (in  which  case  Q  in  the  code  holds  to  the 
Previous  object). 

Fig.  7-2  illustrates  the  recognition  of  Iterative-generation  in  the  surface  plan  for  bucket-delete. 
Iterative-generation  is  the  plan  for  repeatedly  applying  a  given  function  (the  same  function  each  time)  to 
the  output  of  the  preceding  application  of  that  function.  This  plan  has  two  roles:  Action  and  Tail.  Action 
is  an  instance  of  ©Function,  in  which  the  function  is  applied:  Tail  is  the  standard  recursive  invocation. 
Delete-loop  can  be  analyzed  as  Iterative-generation  by  identifying  Delete-loop.One  with  Iterative- 
gencration.Action,  as  shown  in  the  figure. 

Following  the  recognition  of  Trailing-search  and  Iterative-generation,  the  system  also  checks 
whether  any  standard  specializations  or  extensions  of  these  plans  are  applicable.  In  this  example,  the 
system  finds  Trailing-generation+search  in  the  library,  which  is  an  extension  of  both  T  railing-search  and 
Iterative-generation.  Trailing-generation+search  has  five  roles:  Exit,  Current  and  Previous  (inherited 
from  Trailing-search);  Action  (inherited  from  Iterative-generation);  and  Tail  (recursively  defined  as  in 
both  Trailing-search  and  Iterative-generation).  Trailing-generation+search  also  inherits  all  the  constraints 
between  these  roles  from  both  Trailing-search  and  Iterative-generation,  and  adds  one  more,  a  data  flow 
constraint  between  Action.Output  and  ExiUfJnpuL 

When  the  system  tries  to  recognize  Trailing-generation+search  in  Delete-loop,  it  finds  that  only  one 
constraint  is  missing  —  the  data  flow  from  Action.Output  to  Exit.If.lnput.  Furthermore,  this  is  taken  to 
be  a  near-miss,  rather  than  a  simple  failure  to  match,1  and  the  following  message  is  generated  warning  the 
programmer  about  a  potential  error. 

WARNING!  THE  LOOP  IN  BUCKET-DELETE  IS  ALMOST  A 
TRAILING  GENERATION  AND  SEARCH, 

CURRENT:  P 
PREVIOUS:  Q 

EXIT:  (COND  ((EQUAL  (CAAR  P)  ...)>) 

ACTION:  (CDR  P) 

EXCEPT  THAT  THE  OUTPUT  OF  THE  ACTION  IS  N£T  EQUAL  TO  THE 
INPUT  OF  THE  EXIT  TEST. 

Notice  that  because  this  warning  message  is  generated  as  the  result  of  a  near-miss  recognition,  the 
programmer  gets  much  more  contextual  information  than  would  result  from  detecting  this  error  by  other 
means  (e.g.  by  noticing  that  the  variable  Q  could  be  used  before  it  is  set).  In  particular,  the  system  is  able 
to  identify  the  roles  played  by  the  parts  of  the  program,  i.e.  P  and  Q  are  not  just  any  variables  in  the 
program,  but  arc  the  current  and  previous  values  of  a  trailing  search,  and  so  on.  This  information  makes 
it  easier  for  the  programmer  to  correct  the  problem. 


1.  The  exact  criteria  for  distinguishing  in  general  between  near-misses  and  failures  to  match  will  have  to  be  determined 
experimentally. 
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CHAPTER  EIGHT 
LOGICAL  FOUNDATIONS 


8.1  Introduction 

The  preceding  chapters  have  focused  on  how  the  plan  calculus  can  be  used  in  a  program 
understanding  system,  such  as  a  programmer’s  apprentice.  This  chapter  takes  a  more  semantic  and 
formal  approach  to  plans.  We  begin  by  defining  a  logical  language,  similar  to  the  situational  calculus 
used  by  Green  [31]  and  McCarthy  and  Hayes  [44],  which  is  adequate  for  expressing  the  fundamental 
computational  concepts  underlying  the  plan  calculus. 

We  then  use  the  situational  calculus  to  provide  a  semantic  foundation  for  the  plan  calculus  by 
giving  rules  for  translating  plans  into  sets  of  axioms  in  the  situational  calculus.  The  presentation  of  these 
rules  will  be  done  in  two  stages.  First  we  will  develop  enough  of  the  situational  calculus  to  support  the 
semantics  of  data  plans  and  data  overlays.  We  will  then  add  a  notion  of  temporal  order  and  give  the 
translation  rules  for  temporal  plans  and  temporal  overlays. 

One  important  reason  for  providing  a  formal  semantics  for  the  plan  calculus  is  in  order  to  state 
precisely  the  rules  of  inference  on  plans.  These  rules  of  inference  provide  the  answers  to  questions  such 
as  whether  one  plan  subsumes  another,  and  whether  one  plan  is  a  correct  implementation  of  another. 
This  is  particularly  important  in  order  to  pre-verify  plans  in  the  plan  library. 

In  most  of  this  chapter,  examples  of  Lisp  computations  will  be  used  to  motivate  various  aspects  of 
the  formalism.  However,  the  logical  framework  developed  here  is  equally  applicable  to  other 
conventional  sequential  programming  languages. 

8.2  Mutable  Objects  and  Side  Effects 

The  everyday  world  of  physical  objects  is  a  system  with  mutable  objects  and  side  effects.  For 
example,  if  1  drill  a  hole  in  my  dining  room  table,  I  normally  choose  to  think  of  it  as  the  same  object  even 
though  it  now  behaves  differently  (i.e.  has  different  properties).  Similarly  for  a  hierarchically  structured 
object,  such  as  an  automobile,  changing  some  of  the  parts  (for  example  replacing  the  brake  linings)  is 
normally  viewed  as  a  side  effect,  rather  than  resulting  in  a  new  automobile  which  has  many  of  the  same 
parts  as  the  original. 

The  question  of  side  effects  is  tied  up  with  the  phenomenon  of  naming.1  As  observers  of  the 
system,  we  choose  to  use  the  same  name  for  the  dining  room  table  and  the  automobile  at  two  different 
points  in  time,  despite  the  fact  that  they  have  been  modified.  The  notioc  of  mutable  objects  thus  involves 


1.  Sussman  and  Steele  give  a  very  good  illustration  of  this  point  in  the  context  of  programming  language  interpreters  in  [66]. 
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two  aspects:  identity  and  behavior.  The  identity  of  a  mutable  object  is  unchangeable;  its  behavior  can 
change  over  time. 

Syntax 

The  language  we  will  use  to  express  these  ideas  formally  is  calted  a  situational  calculus. 
Syntactically,  this  will  be  a  standard  first  order  logical  language  with  constants,  variables,  function  and 
relation  symbols,  logical  connectives  (A,  v,  D  and  «-»),  quantifiers  (V  and  3),  and  equality  (=  and  *). 
Set  theory  (e  and  <)  and  integer  arithmetic  (Plus,  Times,  Gt,  etc.)  are  taken  for  granted. 

Basic  Semantic  Domains 

The  identity  of  a  mutable  object  is  embodied  in  its  name.  The  set  of  names  is  called  P.  If  p  is  a 
name,  wc  will  commonly  say  "the  object  p",  rather  than  more  precisely  "the  object  named  by  p".  Names 
are  similar  to  what  arc  called  pointers  in  computer  science. 

The  universe  of  possible  behaviors  is  called  U.  Think  of  U  as  a  universe  of  mathematical  entities 
which  are  used  to  describe  the  properties  of  objects  at  given  points  in  time.  For  example,  suppose  we 
want  to  talk  about  mutable  sets;  U  would  then  be  the  universe  of  mathematical  sets.1  A  nice  feature  of 
this  approach  is  that  U  can  be  treated  strictly  as  formal  domain  (with  an  equality  relation),  i.e.  the  formal 
treatment  of  mutability  is  independent  of  the  theory  of  each  kind  of  behavior. 

Time  is  represented  as  a  set  of  situations,  S.  Situations  are  denoted  in  the  language  by  constant 
symbols  such  as  s  and  L  In  this  section,  wc  are  interested  only  in  a  notion  of  time  for  distinguishing 
different  behaviors  of  mutable  objects.  In  a  later  section,  a  primitive  ordering  relation  on  situations  will 
be  introduced  for  specifying  the  flow  of  control  in  computations. 

Behavior  Functions 

The  behavior  of  an  object  at  a  given  point  in  time  is  expressed  by  a  behavior  function,  which  maps  a 
name  and  a  situation  to  a  behavior. 

B:  PXS~*U 

The  term  B(p,s),  where  B  is  a  behavior  function,  may  be  thought  of  as  expressing  the  "state  of 
object  p  at  s”.2  The  notion  of  whether  or  not  an  object  p  exists  at  time  s  is  represented  by  mapping  the 
behavior  of  p  in  some  situations  to  a  distinguished  clement  of  U  called  Undefined. 

Generally  speaking,  a  computing  system  provides  the  user  with  a  set  of  primitive  names  and  one  or 
more  primitive  behavior  functions,  out  of  which  all  other  mutable  objects  arc  built  For  example,  in  Lisp 
the  primitive  names  arc  the  pointers  (addresses)  of  oons  cells,  arrays,  and  atoms.  The  primitive  behavior 
functions  specify  the  dotted  pair  behavior  (i.e.  the  car  and  cdr)  of  cons  cells  at  given  points  in  time;  the 


1.  It  will  I alcr  turn  out  that  U  and )’  need  not  be  disjoint,  but  this  assumption  makes  this  initial  exposition  simpler  to  understand. 

2.  We  will  sec  later  that  many  dilfercnt  behavior  [unctions  can  be  used,  corresponding  to  different  views  of  an  object 
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array  behavior  (i.e.  the  current  function  from  indices  to  objects)  of  array  pointers;  and  the  property  list  of 
atom  pointers. 

Equality 

Equality  in  P,  S  and  U  is  denoted  by  "  =  ",  with  the  usual  rule  of  substitution.  We  first  consider  the 
intuitive  meaning  of  equality  in  these  three  domains,  and  then  discuss  how  the  notion  of  side  effect  is 
represented  using  equality. 

Intuitively,  p  =  q,  for  two  names,  p  and  q,  means  that  p  and  q  are  different  names  for  the  same 
mutable  object.  This  could  arise,  for  example,  if  we  introduced  two  anonymous  objects  named  p  and  q, 
and  then  wanted  to  consider  what  would  happen  if  they  were  the  same  object. 

Intuitively,  s=t,  for  two  situations,  s  and  t,  means  that  the  behavior  of  all  mutable  objects  is  the 
same  in  s  and  t  We  express  this  formally  as  the  Axiom  of  Extensionality  for  Situations,  which  has  the 
following  form  (where  B,C,...  are  behavior  functions). 

Vsf  [  Vp  [  B(p,s)= B(p,f)  a  C(p,s)=C(p,t)  A  ...  J  D  s=  t  ] 

For  a  given  computing  system  it  is  adequate  to  include  only  the  primitive  behavior  functions  in  this 
axiom.  For  example,  for  Lisp,  two  situations  are  equal  in  which  all  cons  cells  have  the  same  car  and  cdr, 
all  arrays  have  the  same  items,  and  all  atoms  have  the  same  property  lists.  Later  in  this  chapter,  we  will 
extend  this  axiom  to  distinguish  situations  which  are  temporally  distinct,  but  in  which  the  behavior  of  all 
objects  is  the  same. 

Equality  in  \J  is  the  equality  relation  for  the  particular  mathematical  domain  used  to  represent 
behavior.  For  example,  if  U  is  sets,  then  normal  set  equality  is  used. 

Side  Effects 

We  speak  of  a  side  effect  having  occurred  when  an  object  behaves  differently  in  two  situations. 
Formally  this  is  when  for  some  behavior  function,  B,  and  situations  s  and  t, 

B(p,s)*B(p,t)  _ 

We  say  here  that  p  has  been  modified.  For  example,  to  describe  the  side  effect  in  which  the  integer 
3  is  removed  from  the  mutable  set  p  which  originally  contains  the  integers  1,  2,  and  3  we  write  the 
following. 

sct(p,s)={  1,2,3} 

set(p,t)={l,2} 

To  say  that  the  behavior  of  an  object  p  is  the  same  in  two  situations,  s  and  t,  we  write  B(p,s)  =  B(p,t). 

Note  that  this  approach  to  representing  side  effects  differs  from  that  token  by  Green.  McCarthy  and 
Hayes.  In  their  calculus,  an  extra  situational  variable  was  added  to  all  the  function  and  relation  symbols 
which  described  time-dependent  aspects  of  objects.  So  for  example,  for  a  mutable  set  p  they  would  write 
mcmber(x,p,s)  to  assert  that  x  is  a  member  of  p  at  time  s.  At  some  other  time  t*s,  it  then  might  be  the 
case  that  ->member(x,p,t). 
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This  situational  notation  becomes  awkward,  however,  when  one  introduces  defined  relationships 
between  objects.  For  example,  suppose  we  wish  to  assert  that  between  situations  s  and  t  some  elements 
may  have  been  removed  from  set  p,  but  none  have  been  added.  The  appropriate  relation  to  use  here  is 
subset  In  Green,  McCarthy  and  Hayes’  approach  we  are  forced  to  define  subset  as  follows,  adding  two 
situational  arguments: 

subset (p,q,s,t)  s  Vx  [  member(x, p,s)  D  member(x,^,r)  ]. 

We  then  would  then  assert  subset(p,p,t,s)  to  specify  the  indicated  side  effect  In  contrast,  the 
situational  calculus  introduced  here  allows  us  to  preserve  the  standard  algebra  of  set  relations.  So  for 
example  we  could  write 

set(p,t)  C  set(p,s) 

to  specify  the  side  effect  discussed  above. 

Behavior  Types 

In  practice,  we  want  to  use  many  different  mathematical  domains,  such  as  pairs,  sequences,  sets, 
integers,  lists,  etc.,  to  specify  the  behavior  of  mutable  objects.  These  sub-domains  of  U  are  called 
behavior  types. 

The  details  of  how  a  behavior  type  is  specified  are  not  important  for  this  level  of  discussion.  For 
now  we  can  think  of  a  type  as  providing  two  things:  a  predicate  on  elements  of  U  which  distinguishes 
behaviors  of  that  type  from  other  behaviors,  and  a  rule  for  determining  equality  between  behaviors  of 
that  type.  For  example,  for  dotted  pairs,  tlv  type  predicate  is  Dotted-pairp,  and  the  rule  for  equality  is  an 
axiom  which  says  that  two  dotted  pairs  are  equal  if  their  CAR  and  cdr  are  equal,  as  shown  in  Table  8-A. 

Associated  with  each  behavior  type  we  usually  define  a  behavior  function  which  maps  to  elements 
of  that  type.  For  example,  Dotted-pair  is  the  primitive  behavior  function  of  Lisp  which  specifies  the 
dotted  pair  behavior  of  a  cons  cell  at  a  given  point  in  time.  This  function  thus  has  the  following 
relationship  to  the  type  predicate  Dotted-pairp.  (In  the  following  local  context  Greek  letters  will  be  used 
for  elements  ofll.) 

Vps  [a = dotted-pair(p,s)  D  [  dotted-pairp(a)  v  a  =  undefined  ]  J 


table  8-A.  Axioms  for  Dotted  Pairs. 


Axiom  of  Exlensionalily 

Vxy  [  ( dottcd-pairp(x)  A  dottcd-pairp(y)  A  car(x)=carO')  A  cdr(x)=cdr(y)  ]  D  x=y] 
Axiom  of  Comprehension 


V*>’[(  x* undefined  A  y*undcfmcd  ]  D  3z  [  dotted -pairp(z)  A  car(z)= x  A  cdr(z)=y]J 
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Alternatively,  we  can  (and  will)  take  the  approach  of  considering  the  behavior  function  rather  than 
the  type  predicate  as  primitive.  For  example,  for  dotted  pairs,  we  can  define  the  type  predicate  in  terms 
of  the  behavior  function  as  follows. 

dotted-pairp(x)  =  [  3ps  dotted-pair(p,j)= x  A  x*  undefined  1 

In  general,  for  type  T  (formally  a  behavior  function),  we  can  always  write 

1 3psT(p,s)  =  x  A  x*  undefined  ] . 

where  we  need  to  assert  a  type  predicate  on  x.  Furthermore  this  will  be  abbreviated1 
instance(T,jr) . 

Function  Objects 

Many  plans  in  the  library  are  parameterized  with  respect  to  functions  and  relations.  For  example,  a 
directed  graph  is  modelled  as  a  set  of  nodes  and  an  edge  relation.  The  accumulation  loop  plan  abstracts 
away  from  which  particular  aggregative  function  (e.g.  Plus,  Times,  Union)  is  used.  We  also  need  to  talk 
about  functions  as  mutable  objects.  For  example,  splicing  operations  are  viewed  as  side  effects  to  the 
edge  relation  of  a  graph. 

In  order  to  formalize  such  plans,  we  introduce  functions  as  a  behavior  type  in  U.  The  standard 
technique  for  doing  this  is  in  a  first  order  language  is  to  introduce  the  function  symbol.  Apply  (and 
Binapply  for  functions  of  two  arguments,  etc.),  which  is  axiomatized  as  shown  in  Table  8-B.  For  basic 
functions,  such  as  Plus,  Times,  etc.  which  we  want  to  use  both  as  first  order  function  symbols  and  as 
elements  of  U,  we  introduce  corresponding  underlined  symbols  such  as  Plus.  Times,  etc.  with  axioms 
such  as  the  following. 


Table  8-B.  Axioms  for  Functions. 

Axiom  of  Exlensionalily 

Vfg  [  [  instancc( function/)  A  instance( function, g)  A  Vx  apply(/»=apply(g,x)]  3/=g] 

Axioms  of  Comprehension 

'ixy  3/[  instance! function/)  A  apply (fx)=yj 

V/g[  instance( function/)  A  instancc( function, g) 

D  3A[  instance! function/) 

A  Vx[  ( apply/x)  =  undefined  D  apply(/i,x) = apply(g.x)  ] 

A  l  apply(g,x)= undefined  o  apply(A,x)= apply/x)  j  ]  ]  ] 


1.  Instance  must  be  formally  treated  as  a  syntactic  abbreviation  in  order  to  keep  the  language  first  order. 


/ 
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V*  applyfoneplus.*) = oneplus(jr) 

Furthermore,  given  this  convention,  we  will  usually  omit  the  underlining  since  the  underlined 
symbols  can  appear  only  as  terms,  which  are  syntactically  distinct  from  function  symbols  in  a  first  order 
language. 

Relation  objects  are  modelled  as  boolean  valued  functions.  For  example,  the  element  of  U  which 
corresponds  to  the  arithmetic  binary  relation,  Gt,  is  axiomatized  as  follows. 

Vxy  [  binappty(gi,xj') = true  *♦  gt (jqy)  J 

Sequences  are  treated  as  functions  on  a  range  of  integers  (basically  that  a  sequence  is  a  function 
defined  for  all  integers  between  1  and  the  length  of  the  sequence).  This  makes  it  convenient  to  model 
vectors  in  Lisp  as  mutable  sequence  objects.  For  example,  to  describe  a  store  operation  in  which  the  first 
item  of  a  vector  p  is  changed  from  3  to  4,  we  write  the  following. 

apply(scquence(p4).l) = 3 
apply(sequence(p,tXl) =4 

As  an  example  of  mutable  function  objects,  consider  a  view  of  Lisp  in  which  Car  and  Cdr  are  the 
names  of  mutable  function  objects,  whose  domains  are  cons  cells.  In  this  view,  rplaca  and  rplaco  are 
modelled  as  modifying  the  function  behavior  of  Cm  and  Cdr.  rather  than  modifying  the  dotted  pair 
behavior  of  a  given  cons  cell.  The  relationship  between  these  two  views  is  expressed  by  the  following 
axioms. 


Vpr  aoplvffunctionfcar.ri.p) = car(dotted-pair(p,s» 

V/w  appl  vf  function(cdr.s).fl) = cdr(dottcd-pair(p,j)) 

8.3  Multiple  Points  of  View 

The  ability  to  view  the  behavior  of  an  object  in  several  different  ways  is  fundamental  to  the  plan 
calculus.  We  also  need  to  represent  objects  whose  behavior  at  a  given  time  depends  on  the  behaviors  of 
other  objects  at  the  same  time. 

As  a  simple  example,  suppose  we  are  using  a  computing  system  in  which  mutable  sets  are  not 
provided  as  primitives.  If  mutable  sequences  arc  available  (either  as  primitives  or  themselves  built  out  of 
some  other  mutable  objects),  we  can  in  effect  implement  a  mutable  set  by  viewing  a  sequence  as  the  set  of 
its  range  elements.  This  point  of  view  is  defined  formally  as  follows. 

o=sequcncc>sct(p,s)  =  [  ins't  nce(sct,a)  A 

Va[(a  €  a)  **  3/  [  app!y(sequcnce(p,s),/)= a  A  a *■  undefined]  JJ 

Scquence>set  is  a  behavior  function  for  sets.  Notice  that  the  form  of  this  definition  is  to  construct  a 
set  behavior  function  using  a  sequence  behavior  function,  as  highlighted  below. 

<j=scquencc>sct(/>,s)  =  [  ...sequencers)...  J 
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Wc  can  make  other  definitions  of  this  form  to  describe  how  to  implement  set  behavior  in  terms  of 
list  behavior, 

a =list>set(p,r)  =  [  ...lis  t(p,r>...  ] 
and  sequence  behavior  in  terms  oflist  behavior, 

0 = list>scquence(p,s)  =  [  ...list(p,j)„.  1 

and  so  on.  This  way  of  defining  behavior  functions  in  terms  of  other  behavior  functions  is  the  key  idea  in 
representing  the  implementation  of  mutable  objects. 

Constants 

The  formal  system  defined  above  introduces  a  slight  problem  with  respect  to  constants.  We  would 
like  it  to  be  the  case  that  definitions  like  that  of  Scquence>set  above  express  both  the  implementation 
relationship  between  mathematical  sequences  and  mathematical  sets  and  between  mutable  sequences  and 
mutable  sets.  This  problem  is  solved  by  extending  the  functionality  of  behavior  functions  so  that  their 
first  argument  may  be  cither  a  name  or  an  element  of  U. 

B:  (P  u  U)  X  S  -*  U 

For  each  primitive  behavior  function,  such  as  Set,  Sequence  and  List,  wc  then  define  an  additional 
axiom  which  says  in  effect  that  constants  arc  immutable  objects  which  behave  like  themselves.1  For 
example,  for  Sequence  we  have  the  following  axiom. 

V$  [  instance(sequence,0)  3  Vs  sequence(0,r)=0  J 

Sharing 

Related  to  the  notion  of  mutable  objects  and  multiple  points  of  view  is  the  fact  that  two  objects  can 
share  structure.  The  significance  of  sharing  is  that  side  effects  on  an  object  propagate  to  become  side 
effects  on  other  objects  with  which  it  shares  structure.2  For  example,  in  Lisp,  a  single  rplaca  can  modify 
the  behavior  of  several  different  list  objects. 

Sharing  arises  out  of  implementations  which  involve  names.  In  order  to  describe  such 
implementations,  wc  need  to  make  names  part  of  U. 

PCU 

In  other  words  we  can  have  pairs  of  names,  sets  of  names,  sequences  of  names,  etc.  Given  the 
convention  introduced  above  that  behaviors  name  themselves,  this  means  that  the  functionality  of 
behavior  functions  is  now  simply 


1.  This  is  similar  lo  the  idea  in  Lisp  that  constant  such  as  T,  ttIL  and  integers,  evaluate  to  themselves. 

2.  Ihis  phenomenon  is  also  sometimes  called  “aliasing". 
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B:UXS-»U. 

Since  we  still  want  to  distinguish  those  elements  of  U  which  are  not  names;  we  define  the  set  of 
constants,  V,  as 

V  =  UP. 

The  easiest  way  to  explain  how  shared  structure  and  the  propagation  of  side  effects  arises  from  the 
use  of  names  is  by  an  example.  Consider  implementing  a  (mutable)  set  as  a  (mutable)  sequence  of 
disjoint  (mutable)  sets,  such  that  an  object  is  a  member  of  the  implemented  set  iff  it  is  a  member  of  one  of 
the  sets  in  the  sequence.  This  is  part  of  the  idea  of  hash  tables,  in  which  the  sets  in  the  sequence  are  called 
"buckets”.  This  implementation  can  be  defined  formally  as  follows.  (In  the  following  local  context, 
Greek  letters  will  now  be  used  to  denote  constants.) 

6 = sequence-of-scts(p,  j)  =  [  instancef  sequence,#)  A 

V  ij  [  i*j  D  disjoint(sct(apply(sequence(p,s),0,j),set(apply(scquencc(p,i)j),j))  J  J 

<r=sequencc-of-scts>set(/vs)  s  [  instance!  set,o)  A 

Vx  [  (jr  €  a)  **  3/  (x  6  self  apply  ( sequencers),  i),s))  ]  ] 

Notice,  as  highlighted  below,  that  the  Set  behavior  function  is  used  to  obtain  the  set  behavior  of 
terms  in  the  sequence. 

o = sequcncc-of-sets>set(p,j)  s  l  ._sct(apply(scquencc(p^)1...),s)... ) 

This  means  that  the  terms  in  the  sequence  may  be  names.  By  always  using  behavior  functions  this 
way,  we  provide  for  the  mutability  of  objects. 

Now  let  us  see  how  this  implementation  leads  to  sharing.  In  particular,  let  us  see  how  a  side  effect 
to  any  bucket  amounts  to  a  side  effect  to  the  implemented  set  Consider  a  sequence  named  H  which  is 
viewed  as  implementing  a  set  according  to  the  technique  of  Sequence-of-scts>set  Furthermore,  suppose 
B  is  some  bucket  of  H  at  some  particular  time  s, 

apply(sequence(H,s),i) = B 

and  that  the  sequence  H  is  not  modified  between  s  and  t 

scqucnce(H,s)= sequence(H,t) 

However,  if  B  (and  only  B)  is  modified  between  s  and  t,  ie. 

set(B,s)*sct(B,t) 

Vjlj* i  D  sct(apply(scqucncc(H,s)J),s)=sct(apply(scquence(H,s)t/),t)] 
it  follows  from  the  definitions  above  that  the  Scquence-of-scts>set  behavior  of  H  is  also  modified. 

scquence-of-scts>sct(H,s)*scqucncc-of-scts>sct(H,t) 
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The  general  point  illustrated  by  this  example  is  that  the  potential  for  structure  sharing  and  the 
propagation  of  side  effects  is  introduced  whenever  you  start  to  manipulate  names  (pointers)  as  behaviors. 
It  is  usual  to  think  of  sharing  at  the  lowest  level  of  implementation,  such  as  at  the  machine  language  level, 
or  at  the  cons  cell  level  in  Lisp.  This  example  demonstrates  that  it  may  enter  in  at  any  level  of 
abstraction. 

Sharing  does  not  always  arise  when  pointers  are  used.  For  example,  suppose  we  simultaneously 
view  the  sequence  H  above  as  implementing  a  set  another  way,  e.g.  according  to  Sequencoset.  In  this 
view,  for  the  same  situations  s  and  t,  no  side  effect  has  occurred. 

sequence>set(H,s) = sequence>set(H,t) , 

This  is  because  Sequence>set(H,s)  is  the  set  of  bucket  names,  which  doesn’t  change  even  though 
one  of  the  buckets  has  been  modified.  We  could  give  separate  names  to  these  two  set  vit-ws  of  H,  as 
follows. 

Vs  set(  M,s) = scquence-of-sets>set(H,s) 

Vs  sct(K,s) = sequence>set(H,s) 

The  set  M  can  be  thought  of  as  the  set  of  members  of  the  hash  table,  and  K  the  set  of  buckets. 

Shared  List  Structure  in  Lisp 

As  a  second  example  of  sharing,  we  show  how  to  represent  a  kind  of  sharing  which  should  be  very 
familiar  to  Lisp  programmers  —  shared  list  structure.  This  example  is  more  complicated  than  the  hash 
table  example  mostly  because  of  the  recursive  nature  of  the  definition  of  list  behavior.  The  axioms  for 
lists  are  given  in  Table  8-C. 

Lists  in  Lisp  arc  built  out  of  dotted  pairs  whose  Cdr  is  either  Nil  (a  distinguished  constant)  or  the 
name  of  (pointer  to)  another  such  dotted  pair.  This  is  often  called  the  "linked  list”  implementation.  It  is 
defined  formally  in  terms  of  behavior  functions  as  follows. 


Table  8-C.  Axioms  for  Lists. 

Axiom  of  Extensionality 

Vafipqs  [  [a = listQvs)  A  /J = list (q,s)  A  head(a) = hcad(/))  A  list(tail(a),s) = Iist(tail(/)X$)  ] 
Da=/J) 

Axiom  of  Comprehension 

Vx>j[  [  jr* undefined  A  [ _>>=nil  v  listfv.j)* undefined  ] ) 

*»  3ap(a=list(p,s)  A  a* undefined  A  hcad(a)= x  A  tail(a)=>>] ) 


t 


•  *-•* 


148  CHAPTER  EIGHT 


X  =  dotted-pair>list(p,i)  =  [  [X  =  nil  A  p=  nil  ]  v 
[  instance(Hst,X) 

A  head(X)=car(dotted-pairO>,j)) 

A  tail(X)=dotted-pair>list(cdr(dotted-pair(/>,5)),i)  J  J 

Notice  that  this  is  a  recursive  definition.  The  tail  of  the  implemented  list  is  the  list  implemented  by 
the  cdr  of  the  dotted  pair  (in  the  same  way). 

To  demonstrate  how  this  implementation  of  lists  in  Lisp  entails  structure  sharing  we  show  an 
example  of  how  side  effects  are  propagated.  Consider  three  cons  cells  C,  D,  and  E  (cons  cells  are  names 
with  dotted  pair  behaviors),  such  that  in  situation  s  the  Cdr  of  both  C  and  D  is  E 

cdr(dotted-pair(C,s)) = E 
cdr(dotted-pair{D,s)) = E 

If  we  view  C,  D  and  E  as  implementing  lists  according  to  Dottcd-paiolist,  then  by  the  definitions  above, 
C  and  D  share  tails  in  s,  Le. 

tail(dotted-pair>list(C,s)) = tail(dotted-pair>Iist(D,s)) 

If  we  now  modify  the  Car  of  E  (e.g.  by  rplaca),  without  changing  C  and  D,  so  that 

car(dotted-pair(E,s))*car(dotted'pairfE,t)) 
dotted-pair(C,s) = dottcd-pair(C,t) 
dottcd-pair(D,s) = dotted-pair(D,t) 

it  follows  that 

dotted-pair>list(E,s)*dotted-pair>list(E,t). 

Furthermore,  since  they  share  structure  with  E  viewed  as  a  list,  it  follows  that  the  list  behaviors  of  C  and 
D  have  both  been  modified,  Le. 

dotted-pair>list(C,s)*dotted-pair>list(C,t) 
dbttcd-pair>  list(  D,s)*dotted-pair>  list(D,t) . 

8.4  Data  Plans 

We  arc  now  in  a  position  to  explain  the  meaning  of  data  plans  in  terms  of  the  formal  framework 
developed  in  the  preceding  sections.  The  basic  idea  is  that  a  data  plan  defines  a  new  type  and  an 
associated  behavior  function.  We  will  first  present  an  example,  and  then  outline  the  general  rules  for  how 
to  translate  from  the  data  plan  formalism  to  a  set  of  axioms  in  the  situational  calculus. 

Consider  the  data  plan.  Segment,  shown  in  Fig.  8-1,  which  consists  of  a  sequence  (the  Base)  and  two 
natural  numbers  (Upper  and  Lower),  with  the  constraint  that  Upper  and  I  .ower  are  valid  indices  for  the 
Base,  and  Lower  is  less  than  or  equal  to  Upper. 

In  terms  of  the  formal  framework  developed  in  the  preceding  sections,  the  meaning  of  this  plan  is 
to  define  a  new  behavior  type  with  the  two  axioms  shown  in  Table  8-D.  Ihc  first  axiom  says  that  two 
segments  arc  equal  iff  their  base  sequences  and  upper  and  lower  indices  arc  the  same.  The  second  axiom 
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Figure  8-1.  Segment  Data  Plan. 
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Table  8-D.  Segment  Data  Plan. 

Axiom  of  Extensionality 

Vafipqs[  [a =segment(p,s)  A  /? = segments) 

A  sequence(basc{a  ),s) = sequencc(baseOJ),s) 

A  natural(lower(a),s)  =  natural(lowcr(/J),$) 

A  natural(uppcr(a),s) = natural(upperO?),s)  ] 

3a=/l] 

Axiom  of  Comprehension 

Vxyzs\[ sequencers)*  undefined  A  natural(y,s)*undefined  A  natural! z,s)*undefined 
A  le( natural0’,r)4iatural( z,s)) 

A  le(naturalO,s).lcngth(sequencc!jf,s))) 

A  le(natural(z,j),lcngth( sequence! jr,i)))  ] 

*♦  lap  [a  =  segments)  A  a*  undefined 

A  base(o) =  x  A  lower(a) = y  A  uppcr!a) = z  ]  ] 

DatnPlan  Segment 

roles  .basc!scquence)  .lowertnatural)  .upper! natural) 
constraints  le(.lower,.upper) 

A  le(.lowerJength(.base»  A  k(.upperllength(.base» 


says  that  for  any  sequence  and  two  numbers  which  are  valid  indices  for  that  sequence,  there  exists  a 
segment  with  that  sequence  as  the  base  and  the  two  numbers  as  the  upper  and  lower  indices;  and 
conversely,  that  the  upper  and  lower  indices  of  any  segment  are  valid  indices  for  the  base  sequence  and 
the  lower  index  is  less  than  the  upper. 

Notice  that  behavior  functions  are  used  throughout  these  axioms  to  refer  to  the  behavior  of  the 
parts  of  a  segment.  This  is  necessary  to  allow  for  shared  structure  at  any  level.  For  example  this  means 
that  the  Base  of  a  segment  can  be  cither  a  sequence  of  the  name  of  a  sequence. 

The  general  rule  for  translating  a  data  plan  into  a  set  of  axioms  in  the  situational  calculus  has  two 
steps.  First,  the  name  of  the  plan  formally  becomes  a  behavior  function,  and  the  roles  of  the  plan  become 
functions  on  behaviors  of  that  type.  Second,  two  axioms  are  written  involving  these  functions. 

The  first  axiom  defines  equality  on  the  new  behavior  type  in  terms  of  equality  of  the  appropriate 
behaviors  of  the  roles.  So  for  data  plan  D  with  n  roles  fig,...,  restricted  to  behavior  types  T,U,..., 
respectively,  the  following  axiom  schema  (called  the  axiom  of  extensionality)  is  written. 

Vaflpqs  [  [a  =  D(p,s)  A  /?  =  lXq,s) 

A  ma),s)=mpU)  A  U(g(a),s)=U(g03),s)  A  ...  ] 

3a=j8] 
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The  second  axiom  involves  the  type  restrictions  on  roles  of  a  data  plan  and  the  constraints  between 
roles.  Formally  the  constraints  are  an  n-ary  relation,  where  each  argument  position  corresponds  to  a  role, 
with  an  extra  role  for  the  situation  argument  to  the  behavior  functions  for  each  role  type.  So  for  the  same 
data  plan  D  as  above,  with  constraint  relation,  C,  the  following  axiom  schema  (called  the  axiom  of 
comprehension)  is  written. 

Vsxy...  [  [  T(x,s)*undcfined  A  U(y,s)*undefined  A  ...  A  C(s,x,y,...) ) 

*♦  3ap  [a  =  D(p,s)  a  ^undefined  A  fl[a)=ar  A  g(a)=yA  ...  ]] 

This  axiom  specifies  that  instances  of  the  plan  D  exist,  and  that  all  instances  satisfy  the  role  type 
restrictions  and  constraints. 

Finally,  the  information  in  the  axioms  for  a  data  plan  can  be  written  in  more  compact  tabular  form 
as  shown  at  the  bottom  of  Table  8-D.  This  is  the  notation  that  will  be  used  in  the  remainder  of  this 
document  for  formal  plan  definitions.  In  this  notation,  the  definition  of  the  constraint  relation  is  made 
easier  to  read  by  using  the  role  names  preceded  with  a  leading  point  (such  as  ".base")  instead  of 
quantified  variables  corresponding  to  roles,  as  appear  in  the  fully  written  out  axioms.  Remaining  points 
in  constraint  formulae  are  interpreted  as  normal  function  application.  For  example,  a  path  name  like 
".f.r.s",  where  f  is  a  role  in  the  plan  being  defined,  is  formally  equivalent  to  "sfrf.f))”,  since  r  and  s  are 
other  role  functions. 

An  additional  abbreviation  used  in  writing  constraints  in  data  plans  is  to  make  the  behavior 
functions  applied  to  role  functions  implicit  when  the  behavior  function  is  the  same  as  the  type  restriction 
on  the  role.  For  example,  at  the  bottom  of  Table  8-D, 

le(.upper,length(.base)) 
is  an  abbreviation  for 

le(natural(.upper,s),length(sequence(.base,s))). 

The  type  restriction  on  each  role  of  a  data  plan  is  indicated  in  the  compact  notation  in  parentheses 
following  each  role  name.  For  example,  the  axioms  for  lists  are  rewritten  using  this  notation  as  follows. 

DataPlan  List 

roles  .hcad(objcct)  .tail(list+nil) 

The  type  List+nil  is  defined  by  the  behavior  junction  shown  below. 

X = list+nil(p,s)  s  [X = list(p,s)  v  X  =  nil  ] 

The  absence  of  type  restriction  (other  than  being  defined)  is  indicated  by  the  keyword  "object" 
after  the  role  name.  For  example,  the  axioms  for  dotted  pairs  can  be  rewritten  using  this  notation  as 
follows. 


DataPlan  Dotted-pair 
roles  .caifobjcct)  xdrfobjcct) 


152 


CHAPTER  EIGHT 


8.5  Data  Overlays 

Intuitively,  a  data  overlay  is  a  many-to-one  mapping  from  one  behavior  type  to  another.  Formally, 
a  data  overlay  is  a  behavior  function  which  is  defined  in  terms  of  another  behavior  function.  For 
example,  Scqucnce>set  is  a  data  overlay  for  viewing  a  sequence  as  the  implementation  of  a  set 
Furthermore,  because  of  the  way  overlays  arc  used  in  analysis  and  synthesis,  the  mapping  must  be  total  in 
both  directions.  For  example,  for  the  Scquencoset  overlay  this  means  that  given  any  sequence,  there 
exists  a  set  which  it  implements  in  this  way;  and  conversely,  given  any  set,  there  is  at  least  one  sequence 
which  implements  it  in  this  way.  These  properties  are  written  formally  as  the  two  totality  axioms  shown 
in  Table  8-E.  The  definition  of  Sequencoset  is  also  repeated  in  this  table  for  reference. 

As  in  the  case  of  data  plans,  it  is  more  convenient  to  use  a  compact  tabular  notation  than  to  write 
out  the  definition  and  axioms  for  a  data  overlay  as  in  Table  8-E  The  tabular  notation  that  will  be  used  in 
the  rest  of  this  document  for  data  overlays  is  shown  at  the  bottom  of  the  table.  The  general  rules  for 
recovering  the  fully  written  out  formal  logical  definition  and  axioms  are  as  follow.  In  general,  the 
definition  of  an  overlay  V  from  behavior  type  T  to  behavior  type  U, 

DataOveriay  V :  T  —  U 

is  of  the  following  form. 

y=  V(p,s)  3  [  instance!  U,y)  A  -.y.~T!p,i)-.  ] 

The  content  of  this  definition  is  in  the  formula  relating  y  and  T(p,s)  above.  The  standard  prefix, 
Instance(Uj>),  is  omitted  in  the  tabular  notation.  Furthermore,  two  totality  axioms  are  written  from  the 
type  information  in  the  header  of  the  tabular  notation.  These  axioms  have  the  following  form. 

Vxsf  T(x,s)*  undefined  D  3y[y=V(x,s)]] 

Vys[U(y,*)* undefined  D  3x[y=V(jr,s)]  J 

'.1 


Table  8-E.  Sequence  as  Set  Overlay. 

Totality  Axioms 

Vxs[  sequence! .x,s)*undefincd  3  3y[y=sequence>set(x,s)  J] 

Vys  l  set(y,j)*  undefined  3  3x  [  y=scqucnce>sct(jc,s)  J  J 
Definition 

y= sequence >sct(p,s)  s  ( instanec(scty)  A  Va  [  (a  6  y) «-»  3i apply! sequencers), i)= a  ]] 
DataOveriay  Scquencoset:  sequence  -*  set 

definition  y=$cqucncc>$et(p,s)  =  Va{  (a  €  y)  *■*  3i  apply(sequence(p,s),r)=ar  1 
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3.6  Computations 

In  ihe  plan  calculus,  computations  arc  thought  of  as  structures,  some  of  whose  parts  are  elements  of 
S  (situations)  and  some  of  whose  parts  are  elements  of  U  (mutable  objects  and  constants).  In  order  to 
formally  describe  computations  in  the  situational  cai-'‘>1„,s,  wc  introduce  a  new  domain,  C,  of 
computations.  C  is  divided  into  types  which  are  spcoofC  by  axioms  similar  to  those  used  to  specify 
behavior  types  in  U.  In  the  rest  of  this  section,  after  some  formal  preliminaries,  we  present  axioms  for 
various  computation  types.  In  the  next  section  wc  use  these  foundations  to  specify  the  semantics  of  the 
temporal  plan  formalism. . 

Temporal  Order 

Thus  far  we  have  been  using  situations  only  as  arguments  to  behavior  functions  to  distinguish  the 
different  states  of  objects.  In  order  to  represent  temporal  order  in  computations  we  introduce  a  new 
primitive  relation,  called  Precedes,  which  is  formally  a  total  order  on  S.  Intuitively,  this  relation  captures 
the  notion  of  states  occurring  "before"  or  "after"  other  states.  This  relation  also  makes  it  possible  to  talk 
about  cyclic  computations  in  which  all  objects  return  to  the  same  state  as  at  some  earlier  time.  Formally, 
this  is  achieved  by  extending  the  Axiom  of  Extensionality  for  Situations  as  follows. 

Vs/  [f  Vpf  B(p,s)=  B (p,t)  A  C (p,s)  =  C(p,t)  A  ...  ] 

A  Vu  [  precedcs(s,u)  •*-»  preccdcs(/,M)  ]  ]  D  s=  t  ] 

B,C,...  here  are  the  appropriate  primitive  behavior  functions  as  before.  This  axiom  says  that  two 
situations  are  identical  iff  the  behavior  of  all  objects  is  the  same  and  they  arc  indistinguishable  in  the 
temporal  order. 

Note  that  Precedes  is  a  total  order.  This  is  because  we  are  formally  dealing  with  sequential 
computations.  As  we  will  see  shortly,  however,  in  specifying  computation  types  we  will  often  leave  tht 
order  between  two  steps  unconstrained. 

Termination 

Another  basic  feature  of  computations  we  need  to  deal  with  is  termination.  In  order  to  talk  about 
this  formally,  we  introduce  a  bottom  element  in  S,  Le. 

Vjprccedes(s,X). 

Intuitively,  J.  represents  a  computation  step  which  is  never  reached.  As  we  shall  see  in  the 
following  sections,  -L  appears  in  the  axioms  for  elementary  computation  types,  such  as  operations  and 
tests.  The  termination  properties  of  composite  types,  such  as  loops,  are  then  derived  from  the  axioms  of 
the  components  and  their  connections.  Important  termination  properties  arc  whether  or  not  a  given  step 
is  reached  in  all  instances  of  a  computation  type,  and  whether  there  exists  an  instance  of  a  computation 
type  in  which  a  given  step  is  reached.  Formally  these  properties  amount  to  the  claim  that  the  situations  in 
question  arc  not  equal  to  ±. 


i 

I  . 
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Operations 

The  most  basic  computation  types  arc  operations.  Operations  in  general  involve  two  situations,  one 
of  which  precedes  the  other,  and  some  number  of  input  and  output  objects.  An  example  of  such  a  type  is 
set  addition  operations.  Intuitively,  a  set  addition  computation  is  an  operation  involving  three  objects: 
the  old  set,  the  new  set,  and  the  member  added.  This  is  specified  formally  by  the  two  axioms  shown  in 
Table  8-F.  These  axioms  involve  the  type  predicate.  Set-add,  and  the  functions  In,  Out,  Old,  New,  and 
Input,  on  elements  of  the  type  which  act  like  the  role  functions  of  a  data  structure  (e.g.  Head  and  Tail  for 
lists).  For  example,  consider  two  situations,  s  and  t,  and  mutable  sets  A  and  D,  such  that  the.  following 
statements  hold. 

precedes(s,t) 

set(A^)={U> 

set(B,t)={lA3} 

Formally,  what  we  have  here  is  a  computation,  a ,  such  that 

set-add(a) 

in(«)=s 

out(«)=t 

okK«)=A 

input(a)=3 

ncw(a)=B. 


Table  *-F.  Set  AMMaa  Operations. 

Axiom  ofExtenskmality 

Vafi  [  l  set-add(a)  A  set-add(fi)  A  in(a) = A  outfo) = out(j9) 

A  old(o)=old(j?)  A  input(a)  =  input(/?)  A  ncw(a)= new(jj)  ]  u  a=fi] 

Axiom  of  Comprehension 

Vxyzst  [  [  precedesfi,/)  A  [  s*  JL  o 

[  t*  J.  A  set(x,s)* undefined  A  setO’,0* undefined  A  z*  undefined 
A  (z  €  setO,/)) 

AVw{tv^z3[(w€  SCtCp,/))  ♦-*  (w€  sct(x,5»]])]] 

♦*  3a  [  sct-add(a)  A  in(a)= s  A  out(a)= I 

A  old(a)=x  A  ncw(a)=;>A  inputfa)  =  z  ]  ] 

lOspec  Set-add  /  .old(set)  .input! object)  =*  .new(set) 
postconditions  (.input  C  .new) 

A  Vx  ( x*  .input  D I  (.input  €  .new)  ♦+  (.input  €  .old) )  1 
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In  the  following  local  context  Greek  letters  will  be  used  to  denote  elements  of  C.  Note  that  we  will 
also  informally  refer  to  elements  of  C  as  instances  of  a  computation  type,  T.  Formally,  this  just  means 
T(a). 

The  first  axiom  in  Table  8-F  defines  equality  of  set  addition  operations  in  terms  of  equality  of  the 
situations  and  objects  involved.  The  second  axiom  specifics  a  necessary  and  sufficient  condition  between 
the  objects  and  situations  of  set  addition  operations.  These  axioms  amount  to  what  is  standardly  called  an 
input-output  specification. 

l  et  us  now  pay  attention  to  the  details  of  the  second  axiom  in  Table  8-F.  Part  of  the  necessary  and 
sufficient  condition  deals  with  the  temporal  order  and  termination  properties  of  set  addition  operations, 
as  shown  below.  (This  pattern  of  specification  is  followed  for  operations  in  general). 

[  precedesfs,/)  A  [  j*X  D  ( t*  X  A  ...  ]  ]  ] 

Thus  the  In  situation  precedes  the  Out  situation.  Furthermore,  if  the  In  situation  is  reached,  it 
follows  that  the  Out  situation  is  reached,  i.e.  the  operation  always  terminates.  Notice  that  it  follows  from 
this  axiom  and  the  definition  of  _L  that,  if  the  In  situation  is  never  reached  (i.e.  s=  _L),  then  the  Out 
situation  is  never  reached  (l = -L). 

The  remainder  of  the  condition  part  of  the  second  axiom  specifies  that  the  members  of  die  New  set 
in  the  Out  situation  are  exactly  the  members  of  the  Old  set  in  the  In  situation,  with  the  sole  addition  of 
the  Input  object.  This  relationship  is  conditionalized  inside  t*±  to  avoid  contradiction  in  the  case  when 
neither  situation  is  reached,  i.e.  s=  i=  X. 

Notice  that  this  specification  uses  the  Set  behavior  function  in  referring  to  the  Old  and  New  objects. 
This  means  that  instances  of  this  computation  type  include  both  operations  in  w  hich  the  input  and  output 
sets  are  distinct  objects,  and  those  which  involve  a  side  effect  (e.g.  suppose  old(a)  =  ncw(a)  in  the 
example  above).  More  will  be  said  about  plans  involving  side  effects  at  the  end  of  this  chapter. 

A  more  compact  tabular  notation  for  writing  input-output  specifications  is  shown  at  the  bottom  of 
Table  8-F.  The  first  line  of  this  notation  lists  the  name  of  the  operation  type  (formally  a  predicate  on 
computations),  separated  by  a  slash  from  the  input  roles,  separated  by  a  double  arrow  from  the  output 
roles.  Type  restrictions  are  indicated  in  parentheses  following  the  role  names,  as  in  the  compact  data  plan 
notation.  Roles  arc  formally  functions  on  computations.  To  recover  the  formal  axioms  from  this  notation 

for  a  general  input-output  specification,  P,  with  input  roles  f,g . and  output  roles  m,n,...,  we  first  write  an 

axiom  of  cxtensionality  of  the  following  form. 

Va/?  l[  P(a)  A  P (fi)  A  in(a)=in(/J)  A  out(a)=out(/)) 

A  fla)=f(/?)  A  g(a)  =  g(/?)  A  ...  A  m(a)=m(j8)  A  n(a)  =  n(fi)  A  .„] 

Da=/3] 

The  constraint  between  roles  in  an  input-output  specification  is  made  easier  to  read  in  the  compact 
tabular  notation  by  using  the  role  names  preceded  with  a  leading  point  instead  of  quantified  variables, 
similar  to  the  constraint  notation  for  data  plans.  F.mbcddcd  points  arc  interpreted  as  normal  functional 
nesting. 
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Like  the  compact  notation  for  data  plans,  the  application  of  behavior  functions  corresponding  to 
role  types  is  also  made  implicit  in  compact  input-output  specifications.  For  example,  at  the  bottom  of 
Table  8-F 


(.input  €  .new> 
is  an  abbreviation  for 

(.input  €  set(.new,.in)) . 

By  convention,  the  situational  argument  to  such  implicit  behavior  function  applications  is  either 
".in"  or  ".out",  depending  on  whether  the  role  involved  is  an  input  or  an  output.  No  behavior  function  is 
supplied  for  roles,  such  as  Input,  without  type  restriction  (indicated  by  the  keyword  Object  as  in  data 
plans). 

After  expanding  all  abbreviations  as  outlined  above,  the  constraint  relation  is  formally  a  relation,  G, 
where  each  argument  position  corresponds  to  a  role,  plus  two  situational  arguments  which  correspond  to 
In  and  Out  In  general  for  an  input-output  specification  P  with  input  roles  fg,...,  with  type  restrictions 
and  output  roles  mav~,  with  type  restrictions  A.B^.we  then  write  the  following  axiom. 

Vxrjr>’...vH'_  [  [  prccedesf&r)  A  [  s*_L  D 

[  r*±  A  TLv)* undefined  A  UOvj)*undefined  A  _ 

A  A(v,i)*  undefined  A  B undefined  A  — 

A  v,  Wt—)  111 

♦*  3a  ( F(a)  A  in(a)=jA  out(a)=/ 

A  fta)=Jr  A  g(a)=y  A  _  A  m(a)=v  A  n(a)  =  w  A  _  JJ 

Finally,  note  that  the  constraint  clauses  in  an  input-output  specification  are  divided  into  those 
which  involve  only  input  roles  (called  preconditions),  and  those  which  involve  both  input  and  output 
roles  (called  postconditions).  For  example,  the  following  is  the  compact  specification  of  @Function,  the 
operation  of  applying  a  function  to  an  argument  to  get  the  corresponding  range  element 

IOspec ©Function /.op( function)  .input(object)  =>  .output(object) 
preconditions  apply(.op,.input)*undcfined 
postconditions  apply(.op,.input) = .output 

Tests 


The  second  basic  computation  type  in  the  plan  calculus  is  tests.  Tests  in  general  have  three 
situational  roles:  an  input  situation,  In,  and  two  alternative  following  situations.  Succeed  and  Fail,  only 
one  of  which  is  reached  in  any  instance. 

An  example  of  a  type  of  test  membership  tests,  is  shown  specified  formally  in  Table  8-G.  The  first 
axiom  is  the  usual  axiom  of  extcnsionalily  which  defines  equality  on  a  computation  type  in  terms  of 
equality  of  its  roles.  The  roles  of  a  membership  test  arc  the  three  situational  roles.  In,  Succeed  and  Fail, 
and  two  object  roles.  Universe  (a  set)  and  Input. 
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Tabic  8-G.  Membership  Tests. 

Axiom  of  Extensionality 

Va/3  [(member?(a)  A  member?!/?)  A  in(a)=in(/?)  A  succeed(a)=succeed(/?)  A  fail(a)=fail(/?) 
A  universe(a)  =  universe!/?)  A  input(a)= input(/?)  ]  D  a=fi  ] 

Axiom  of  Comprehension 

Vxystu  [  [  precedes! 5,/)  A  precedes!  *,i/)  A  [  /=  1  v  u=  i  ] 

A  [s*J.  3)  [ [ _L  v  u*±  ] 

A  ^undefined  A  setCy.s)* undefined 
A[/*-L  (jc €  sctCy.s))  ]1]] 

<-»•  3a  [  member?(a)  A  in(a)  =  *  A  succeed(a)  =  /  A  fail(a)=t/ 

A  universe(a)=y  A  input(a)=jc]] 

Test  Member?  /  .universe!set)  .input(object) 
condition  (.input  €  .universe) 


The  second  axiom  in  Table  8-G  says  roughly  that  membership  tests  succeed  if  the  Input  is  a 
member  of  the  Universe;  otherwise  they  fail.  This  is  expressed  formally  by  specifying  the  conditions 
under  which  the  Succeed  and  Fail  roles  are  equal  to  -L,  as  shown  below. 

[  precedes!*,/)  A  precedes!*,//)  A  [  /=  J.  V  u- X  ] 

A[rflD[[l*lV#l)A„,A[(#l«..]]l] 

This  is  the  pattern  of  specification  used  in  general  for  tests.  At  most  one  of  cither  Succeed  or  Fail  is 
reached  in  any  instance.  If  the  condition  of  the  test  is  true  in  the  In  situation,  then  the  Succeed  situation 
is  reached;  if  it  is  false,  then  the  Fail  situation  is  reached.  If  the  In  situation  is  never  reached,  it  follows 
that  neither  Succeed  nor  Fail  are  reached. 

In  the  next  section,  we  will  see  how  tests  specified  this  way  can  be  combined  with  other 
computations,  via  the  notion  of  control  flow,  to  construct  specifications  for  larger  conditional 
computations. 

Finally,  Table  8-G  shows  an  example,  of  the  compact  notation  for  tests.  The  header  line  lists  the 
name  of  the  computation  type  followed  by  the  object  role  names  with  type  restrictions,  similar  to  the 
input-output  specification  notation  introduced  in  the  preceding  section.  The  axiom  of  extensionality 
which  follows  from  this  notation  in  general  is  obvious.  The  axiom  of  comprehension  for  a  test  P?  with 
object  roles  f,g,.'..,  and  type  restrictions  T,U,...,  is  of  the  following  form. 


/ 
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Vstuxy...  [  [  precede s(v)  A  precedes(s,w)  A  [  f=  ±  v  u=±  J 
A[s*±  o[(f*.L  v  u*_L] 

A  T(jt,s)* undefined  A  UCp.s^undefined  A ... 

A  [  /*  _L  «-*•  Qs.jrj',...)  J  j  j  ] 

«-»  3a  ( P?(a)  A  in(a)  =  j  A  succeed(a)= /  A  fail(a)=  u 
A  f(a)  =  jc  A  g(a)=yA  ...  ]  J 

The  relation  C  above  is  derived  by  expanding  abbreviations  in  the  condition  part  of  the  compact 
test  notation  in  the  same  way  abbreviations  arc  expanded  in  the  preconditions  and  postconditions  of  an 
input-output  specification,  supplying  ".in"  as  the  situational  argument  to  implicit  behavior  functions 
where  required. 

8.7  Temporal  Plans 

In  this  section  we  extend  C  by  allowing  parts  of  computations  to  be  not  only  situations  and  objects, 
but  also  other  computations.  ITiis  gives  us  the  ability  to  combine  already  defined  computation  types, 
such  as  operations  and  tests,  into  the  specification  of  larger  computations.  For  example,  we  can  define  a 
computation  type  which  has  two  steps.  The  first  step  is  an  instance  of  ©Discrimination;1  the  second  step 
is  a  membership  test  (Member?).  The  temporal  plan  representation  of  this  computation  type  is  shown  in 
Fig.  8-2.  The  axioms  which  arc  the  formal  translation  of  this  plan  are  given  in  Table  8-H. 


Table  8-H.  Discriminate  and  Member  Plan. 

Axiom  ofExtensionality 

Va/9  [  [  discriminate+member?(a)  A  discriminate+member?(/J) 

A  discriminate(a)= discriminate^)  A  if(a)=ifl(/8)  ]  D  a=/9  ] 

Axiom  of  Comprehension 

Va/9  [  [©discrimination^)  A  member?(/3)  A  cflow(out(a),in(/9)) 

A  set(output(a),out(a))= sct(universe(/9),in(/9)) 

A  input(a)=input(/9)] 

**  35  [ discriminate+member?(5)  A  discriminate^) = a  A  if(5)=/9  ]] 

Temporal  Plan  discriminate+mcmber? 
roles  .discriminatc( ©discrimination)  .if( member?) 
constraints  cflow(.discriminatc.out,.if.in) 

A  .discriminatc.output = .if.uni verse  A  .discriminate.input=.if.input 


1.  ©Discrimination  is  a  specialization  of  @];unction  in  which  the  function  applied  (Op)  is  a  discrimination,  and  therefore  the 
Output  is  a  set. 


temporal  plans 


Figure  8-2.  A  Temporal  Plan 
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Notice  that  the  name  of  the  plan,  Discriminate+mcmber?,  is  formally  a  predicate  on  computations. 
The  roles  of  the  plan.  Discriminate  and  If,  are  formally  functions  on  computations,  like  Old,  In,  Input, 
New,  etc.  in  the  preceding  section.  The  ranges  of  these  role  functions,  however,  are  computations,  as  can 
be  seen  in  the  second  axiom  of  Table  8-H  highlighted  below. 

Va/3  [  [@discrimination(a)  A  member?(/3) ... ) 

**  35 1  discriminate+member?(5)  A  discriminate(5)=  a  A  ]  J 


Table  8-1.  Bump  and  Update  Plan. 

Axiom  of  Extensionatity 

Va/?  [  [  bump+update(a)  A  bump+update(/?)  A  bump(a) = bump(/?)  A  updatefa)  =  update(/J) 

A  old(a)= old(/?)  A  new(a)= new(/?)  ]  D  a  =/J  ] 

Axiom  of  Comprehension 

y/xyafi  l  (@oncminus(a)  A  newterm(j8) 

A  uppcr-scgmcnt(jr,in(a))*  undefined 
A  upper-scgment0’,out(y3))^undefuied 
A  cf)ow(out(a),in(/D) 

A  upper-segment!  x,in(a)) = upper-scgment(x,in(/3)) 

A  upper-scgmentO',out(a)) = upper-scgment(>’,out(/J)) 

A  integcrfinput(a),in(a))=  natural(lower(upper-segment(x,in(a))),in(o)) 

A  sequenccfoldO?),in(/?))=scquencefbasc(uppcr-segment(.x,in(/?))),in(/!?)) 

A  integer(output(a),out(a)) = natural(arg(/?  ),in(/?)) 

A  intcger(output(a),out(a)) = natural(lowcifupper-segmentO',out(a))),out(a)) 

A  sequence! new(/?),out(/3)) = sequence(base(upper-segmcnt0’,out(/}))),out(/3))  J 
*-*  35  [  bump+updatc(5) 

A  bump{5)=tt  A  update(5)=/9  A  old(5)=Jt  A  new(5)=,y]] 
Temporal  Plan  Bump+update 

roles  .bump(@!oncminus)  .update(newtenn)  .old(upper-scgment)  .new(upper-segment) 
consrrot'/ifscflow(.bump.out,.update.in) 

^  *°^.bump.in  ~  '°^.up<late.in 
A  •new  bump  oul  —  ‘^.update. out 
A  ,bump.input=.old.lower 
A  .updatc.old  =  .old.base 
A  .bump.output=.update.arg 
A  .bump.output=.new.lower 
A  .updatc.ncw  =  .ncw.base 
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In  genera!,  the  type  restriction  on  a  role  in  a  temporal  plan  is  cither  a  behavior  type  (formally  a 
behavior  function)  or  a  computation  type  (formally  a  predicate  on  computations).  An  example  of  a 
temporal  plan  which  has  some  of  both  kinds  of  roles  is  shown  in  Fig.  8-3.  'Hie  Old.  and  New  roles  are 
restricted  to  be  instances  of  the  Upper-segment  data  plan;1 2  hump  and  Update  are  operations.1  The 
axioms  for  this  plan  are  shown  in  Table  8-1.  The  axiom  of  comprehension  in  this  table  is  quite  long,  but  is 
of  the  same  general  form  as  the  axiom  of  comprehension  for  Discriminate+mcmber?.  The  first  three  lines 
stipulate  type  restrictions.  For  temporal  roles,  these  are  assertions  of  the  appropriate  computation  type 
predicates,  e.g. 

@oneminus(a)  A  newterm(/)) . 

For  behav  ior  type  roles,  the  assertion  of  a  type  restriction  has  to  include  the  situation  in  which  it  is 
used,  e.g. 

uppcr-scgment(jc,in(a))*undefined 
upper-segmentO’.outOS))*  undefined . 

For  data  roles  that  arc  used  in  more  than  one  place,  additional  equalities  are  added  to  guarantee 
that  the  data  object  is  the  same  in  all  situations  of  use.  For  example,  the  two  lines  following  the  control 
flow  constraint  in  the  comprehension  axiom  of  Bump+update  are  for  this  purpose. 

uppcr-segment(jr,in(a)) = upper-segment(jr,in(0)) 
upper~segment0’,out(a))=upper-scgmcnt0’,out08)) 

The  remaining  equalities  have  to  do  with  data  flow,  which  will  be  discussed  later  in  this  section. 

Control  Flow 

Control  flow  constraints  (hatched  arrows  in  plan  diagrams)  are  formalized  in  the  situational  calculus 
as  follows. 


cflowfv,/)  s  [  precedes^,/)  A  { s=  ±  **  t=  X  ]  ] 

In  other  words,  control  flow  implies  temporal  order  and  termination  is  preserved.  However,  the 
two  situations  do  not  have  to  be  equal. 

Each  control  flow  arc  in  a  temporal  plan  becomes  a  Cflow  clause  in  the  axiom  of  comprehension  for 
the  computation  type.  The  terms  in  this  clause  arc  the  appropriate  In,  Out,  Succeed  or  Fail  roles,  as  read 
from  the  diagram.  For  example,  the  control  flow  arc  in  Fig.  8-2  becomes  the  following  clause  in  the 
comprehension  axiom  of  Table  8-H. 

cflo\v(out(a),in(/9)) 


1.  Uppcr-scgmcnl  is  a  specialization  of  Segment  in  which  the  Upper  index  is  equal  io  the  length  of  the  sequence. 

2.  Ihe  specifications  for  tfrOncminus  and  Ncwtcrm  can  be  found  in  the  appendix. 


<Y\ew  Iu^pc/c-smws'aO 


Figure  8-3.  Another  Temporal  Flan. 


DATA  FLOW  163 


Data  Flow 

A  second  kind  of  "glue"  in  tempora,  plans  is  data  flow.  Data  flow  arcs  in  general  are  translated  into 
equalities  between  names  and  behaviors  in  different  situations.  The  details  of  this  translation,  however, 
depend  on  whether  the  data  flow  is  between  operations  and  tests,  or  whether  it  also  involves  data  plan 
roles,  such  as  Old  and  New  in  Bump+update. 

We  start  with  the  simple  case  of  the  data  flow  arc  in  Discriminate+member?  (Fig.  8-2)  from 
Discriminate.Input  to  If.lnpuL  This  arc  is  translated  into  the  following  clause  in  the  comprehension 
axiom  for  this  plan. 

input(a)=input09) 

This  is  an  example  of  data  flow  between  the  untyped  roles  of  two  operations.  In  other  words,  what 
is  being  passed  between  these  two  operations  is  being  treated  as  a  name.  The  other  data  flow  arc  in 
Fig.  8-2  is  between  Discriminate.Output  (a  set)  and  If.Universe  (a  set).  For  typed  roles,  the  rules  is  to 
write  the  equality  in  terms  of  the  behavior  function  and  the  appropriate  situational  role,  such  as  In  or 
Out,e.g. 

set(output(a),out(a))=set(universe(fi),in(fi)). 

The  distinction  between  whether  or  not  a  data  flow  equality  involves  a  behavior  function  is  similar 
to  the  distinction  between  "call  by  reference"  and  "call  by  value"  in  some  programming  languages. 

Fig.  8-3  shows  data  flow  involving  data  plan  roles.  In  particular,  different  parts  of  Old  and  New  are 
inputs  and  outputs  of  Bump  and  Update.  These  data  flows  are  translated  into  the  equalities  listed  on 
separate  lines  of  the  comprehension  axiom  in  Table  8-1.  The  first  of  these  is 

integer(input(a),in(a))=natural(lower(upper-segment(x,in(a))),in(a)). 

This  is  the  translation  of  the  arc  from  Old.Lower  to  Bump.Input  in  the  plan  representation.  Notice 
how  the  behavior  functions  have  been  supplied  on  both  sides  above,1  and  that  the  situational  arguments 
are  the  In  situation  of  the  consuming  operation. 

scqucnce(old(y3),in(/?))=scquencc(base(upper-scgment(x,in(/?))),in(/?)) 

The  next  data  flow  arc,  shown  above,  is  from  Old.Base  to  Updatc.Old.  Here  again  we  have 
behavior  functions  on  both  sides,  with  the  same  situational  argument,  namely  Update.In.  The  translation 
of  the  two  data  flow  arcs  involving  New  are  similar,  as  shown  below. 

intcgcr(output(a),out(a))  =  naturaKlowcr(upper-scgmentO',out(o))),out(a)) 

sequence!  ncw(/f),out(/?)) = sequcncc(basc(uppcr-scgmcnt(>,out(/?))),out(/?)) 


1 .  The  input  and  output  of  ©Oncminus  arc  of  type  integer.  Natural  is  a  specialization  of  Integer. 
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Finally,  examples  of  Che  compact  notation  for  writing  the  axioms  for  temporal  plans  are  shown  at 
the  bottom  of  Table  8-H  and  Table  8-1.  In  general  for  a  temporal  plan  P  with  roles  f,g,...,  we  write  the 
following  axiom  of  extensionality. 

Vaj8  n  P(a)  A  P05)  A  «a)  =  ftf)  A  g(a)= g(/9)  A  ...  ]  D  a =/9  ] 

The  axiom  of  comprehension  is  of  the  following  form,  where  f,g,...,  are  temporal  roles  with  types 
T.U,...  and  m,n,...  are  data  roles  with  types  A,B . 

Vx>’...vh'...  [  [  T(jr)  A  U(y)  A ... 

A  A(v,...)*  undefined  A  B(w,...)*  undefined  A  ... 

A  ] 

*♦  3a  { P(a)  A  H«)= x  A  g(a)= y  A ...  A  m(a) = v  A  m(a)= w  A  ...  ]  ] 

The  constraint  relation  C  above  is  derived  by  expanding  abbreviations  in  the  constraints  of  the 
compact  notation  in  a  similar  manner  to  the  way  abbreviations  are  expanded  in  compact  input-output 
specifications.  In  particular,  implicit  applications  of  behavior  functions  with  appropriate  situational 
arguments  are  provided  for  path  names  which  terminate  in  roles  typed  by  behavior  functions.  For 
example, 

jf.universe 

in  the  constraints  of  Discriminate+member?  is  expanded  to 
set(.if.universerif.in) . 

C  also  includes  constraints  that  guarantee  an  object  used  in  more  than  one  situation  is  the  same  in 
all  situations  of  use.  Table  8-1  illustrates  all  these  conventions.  To  facilitate  comparison,  the  constraints 
of  Bump+upda' r  in  the  compact  notation  are  written  in  the  same  order  line  by  line  as  in  t**e  fully  written 
out  axiom  above  in  the  table.  The  first  two  lines  of  the  compact  notation  in  Table  E  -  •  following  the 
control  flow  constraint  illustrate  how  situational  arguments  can  be  explicitly  indicated  in  the  compact 
notation  by  subscripts. 

Conditional  Plans 

Fig.  8-4  is  an  example  of  a  conditional  plan  which  computes  absolute  value.1  The  formal  axioms 
for  this  plan,  written  in  compact  notation,  arc  as  follow. 


1.  Lt-zero?  is  the  lest  for  less  than  zero.  ©’Negative  computes  the  negative  of  an  integer. 


CONDITIONAL  PUNS 


Figure  8-4.  A  Conditional  Plan. 
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TemporalPkn  Abs 

roles  .ifllt-zero?)  .then(@negativc)  .end(join-output) 
constraints  cflow(.if.succecd,.thcn.in) 

A  cf!ow(.thcn.out,.end.succeed) 

A  cflow(.if.fail,.end.fail) 

A  .if.input  =  .then.input 
A  .then.output=.cnd.succced-input 
A  .if.input=.end.fail-input 

This  plan  has  two  key  features  which  are  typical  of  conditional  plans  in  general.  First,  notice  the 
control  flow  arc  from  lf.Succecd  to  Then.ln.  The  intuitive  meaning  of  this  arc  is  that  the  ©Negative 
operation  is  to  be  performed  only  if  the  test  succeeds.  This  is  expressed  formally  as  the  following 
property  of  the  Abs  plan,  which  follows  from  the  way  tests,  operations  and  control  flow  have  been 
axiomatized. 

Vo  f  abs(o)  3  [  in(then(a))*-L  *-*  lt(input(if(a)),0)  ]  ] 

Second,  notice  the  data  flow  and  control  flow  arcs  involving  the  join  (End).  The  meaning  of  these 
arcs  is  that  the  output  of  the  join  is  either  If.Input  or  Then.Output,  depending  on  whether  the  test 
succeeds  or  fails.  Stated  formally,  we  want  the  Abs  plan  to  have  the  following  property. 

Vo  [abs(a>  3 

[  [  lt(input(if(a)),0)  3  output(end(a))=ncgative(input(ifl(a)))  1 
A  [-dt(input(iffa)),0)  3  output(end(a))= input(iflo))  ]  ]  J 

This  is  achieved  by  axiomatizing  joins  (with  one  output)  as  shown  in  Table  8-J.  Joins  "e  like  the 
mirror  images  of  tests.  Joins  have  three  situational  roles.  Succeed,  Fail,  and  Out.  Like  tests,  at  most  one 
of  either  Succeed  or  Fail  is  reached  in  any  instance.  Unlike  tests,  however,  joins  do  not  represent  any  real 
computation,  since  the  Out  situation  is  always  equal  to  either  the  Succeed  or  Fail  situation,  depending  on 
which  is  reached.  The  purpose  of  the  join  is  to  state,  in  a  modular  fashion,  the  connection  between  which 


Table  8-J.  Joining  Outputs. 

Axiom  of  Extensionality 

VajS  ( [  join-output(tt)  A  join-output(/?j 

A  succccd( a ) = succeed! /? )  A  fail(a)=  failQJ)  A  out(a)=out(/)) 

A  succccd-input(a)=succccd-input(/J)  A  fail-input(a)=  fail-input(/?)] 

3  a  =/?  ] 

Axiom  of  Comprehension 

'istuxyz[\  [  f=-L  V  «=-L  J  A  [  r=  J.  3  [  s=«  A  ,x=zj]  A  j  u=-L  3(s=/ A  jr=.yjll 
«-»  3a  j  join-output(a)  A  out(a)  =  j  A  succced(a)=  /  A  fail (a)=u 

A  output(a)=ar  A  succced-input(a)= y  A  fail-input(a)~z]] 


i 
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whether  a  test  succeeds  or  fails  and  which  of  two  possible  outputs  is  made  available  for  further 
computation.  'Die  two  possible  outputs  arc  the  Succccd-input  and  Fail-input  roles  of  the  join.  One  of 
these  is  equal  to  the  Output  role  (which  one  depends  on  whether  Succeed  or  Fail  is  reached),  from  which 
data  flow  arcs  to  following  computations  emanate. 

8.8  Temporal  Overlays 

A  temporal  overlay  is  formally  a  function  from  one  computation  type  to  another.  Furthermore,  like 
data  overlays,  this  mapping  must  be  total  in  both  directions.  For  example,  consider  the  temporal  overlay 
shown  in  Fig.  8-5,  which  expresses  how  to  view  instances  of  the  temporal  plan  Discriminate* member?  as 
implementing  membership  tests  on  a  set  implemented  as  a  discrimination  function. 

The  formal  definition  and  totality  axioms  for  this  overlay  arc  given  in  Table  8-K.  Each 
correspondence  in  the  figure  becomes  an  equality  in  the  formal  definition.  UnlabcIIed  correspondences, 
such  as  between  Discriminate.lnput  on  the  left  and  Input  on  the  right  become  simple  equalities  such  as 

input(/3)= input(discriminate(a)) . 


Table  8-K.  Implementing  Membership  in  a  Discrimination 
Totality  Axioms 

Va  [  discriminate+mcmber?(a)  D  3/3  [  mcmber?(/8)  A  /3 =discriminate+member?>mcmbcr?(a)  ]  ] 

V/3  [  member?(/3)  D  3 a  [  discriminate+member?(/3)  A  /?  =  discriminate+mcmber?>membcr?(o)  1  ] 
Definition 

/3  =  discriminatc+membcr?>member/?(a)  =  [  member?(/8) 

A  set(universc(/3),in(/3))=discrimination>sct(op(discriminatc(a)),in(discriminatc(a))) 
A  input(/?)=input(discriminate(a» 

A  in(/3)=in(discriminate(a)) 

A  fail(/?>  =  fail(ifl») 

A  succecd(/9)=succeed(if(a))  ] 

TemporalOverlay  Discriminate+mcmber?>member? :  discriminate* member?  -*  member? 
correspondences 

mcmbcr?.universc=discrimination>sct(discriminate+mcmbcr?.discriminatc.op) 
A  mcmbcr?.input=discriminate+mcmbcr?.discriminate.input 
A  mcmbcr?.in  =  discriminate+mcmbcr?.discriminate.in 
A  membcr?.fail  =  discriminate+mcmbcr?.if.fail 
A  mcmbcr?.succeed  =  discriminate+mcmbcr?.if.succeed 


CHAPTER  EIGHT 


Figure  8-5.  A  Temporal  Overlay. 
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Since  overlays  can  be  used  in  defining  other  overlays,  some  correspondences  in  temporal  overlays 
are  labelled  with  the  names  of  other  overlays.  For  example,  the  correspondence  between 
Discriminatc.Op  on  the  left  and  Universe  on  the  right  is  labelled  with  the  Discrimination >set  overlay.1 
Intuitively,  this  means  that  Discriminate+membcr?.Discriminatc.Op  is  viewed  as  implementing 
Mcmber?.Universe  according  to  Discrimination>set.  This  is  written  formally  in  the  definition  of 
Discriminate+mcrnber'bmcmber?  as  follows. 

set(universe(/?),in(/?))=discrimination>sct(op(discriminate(a)),in(discriminate(a))) 

Notice  that  behavior  functions  are  supplied  for  typed  roles  with  the  appropriate  situational 
arguments  as  usual.  In  general,  the  definition  of  an  overlay  V  from  computation  type  T  to  computation 
type  U,  where  f,g,.„  are  the  role  functions  of  U,  is  of  the  following  form. 

0  =  V(«)  =  [  U(/J)  A  m A  g(j3) A ...  ] 

In  other  words,  there  is  an  equality  for  each  role  of  0  in  terms  of  some  function  of  a.  This  form, 
together  with  the  cxtensionality  axiom  of  U,  guarantees  the  uniqueness  property  of  the  function  V. 

As  with  data  overlays,  it  is  more  convenient  to  use  a  compact  tabular  notation  than  to  write  out  the 
definition  and  axioms  for  a  temporal  overlay  as  in  Table  8-K.  An  example  of  the  tabular  notation  is 
shown  at  the  bottom  of  the  table.  In  general,  from  the  header  line 

TemporulOverlay  V :  T  -*  U 
the  following  two  totality  axioms  are  written. 

V«  [  T(a)  3  30  [  V(fi)  A  0  =  V(a)  ]  ] 

V/J[  U(0)  D  3a  [  T(a)  A  0  =  V(«)  J  ] 

The  definition  of  the  overlay  function  is  abbreviated  in  the  tabular  notation  by  listing  only  the 
equalities  and  leaving  behavior  functions  and  situational  arguments  implicit  in  the  usual  way. 

8.9  Specialization  and  Extension 

In  this  section  we  discuss  two  additional  ways  of  making  use  of  already  defined  plans  in  defining 
new  ones,  namely,  specialization  and  extension. 

Specialization 

The  basic  idea  of  specialization  is  to  define  a  type  whose  instances  arc  a  subset  of  another  type.  A 
common  motivation  for  doing  this  is  to  exploit  the  properties  of  the  subtype  in  some  particular 
implementation.  For  example,  wc  have  earlier  in  this  chapter  defined  a  general  data  plan.  Segment, 
involving  an  upper  and  lower  index  to  a  base  sequence.  One  way  of  implementing  a  mutable  stack  is  to 
use  an  instance  of  Segment  in  which  only  the  lower  index  is  varied  —  the  upper  index  is  always  equal  to 


1.  This  is  a  data  overlay  similar  to  Scqucncc-of-scis>vcl  introduced  earlier  in  this  chapter. 
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the  length  of  the  base  sequence.  We  called  this  plan  Upper*scgmcnt.  The  formal  rclatioi 
Upper-segment  and  Segment  is  captured  by  the  following  statement 

a = upper-segment(p,s)  =  [o  =  segment(p,r) 

A  natural(uppcr(ff ),s)  =  length(scqucnce(base(o),s))  1 

Thus  Upper-segment  is  Segment  with  an  additional  constraint  In  tabular  notation,  tl 
written  as  follows. 

DataPlan  Upper-segment  specialization  segment 
roles  .b'ase(sequcncc)  .lowcrfnatural)  .upper(natural) 
constraints  .upper = length(.base) 

Notice  that  a  specialization  has  the  same  roles  as  the  more  general  plan,  and  that  the  app 
behavior  functions  of  the  appropriate  type  for  each  role  is  abbreviated  in  the  constraints  in  usual 

The  specialization  of  computation  types  is  similar.  For  example,  the  following  is  the  gem 
output  specifications  for  finding  a  node  in  a  directed  graph  (Digraph),  which  satisfies  a  given  pri 

IOspec  Digraph-find  /  ,universe(digraph)  .critcrion(predicate)  =>  ,output(object) 
preconditions  lx  [  node(. universe,*)  A  apply(.critcrion,x) = true  ] 
postconditions  nodc(.univcrse,. output)  A  apply(.criterion,.output)=true 

An  important  special  case  of  directed  graphs  arc  threads,  in  which  each  node  has  a  unique 
and  there  are  no  cycles.  Finding  nodes  in  threads  is  considerably  simpler  than  the  general  < 
computation  type  of  such  operations  is  specified  formally  as  follows. 

thread-find(a)  =  [  digraph-find(o)  A  thread(old(a),in(a))*undefined  ] 

Thus  the  additional  constraint  here  is  an  additional  type  restriction  on  the  Old  role.  (The 
function  Thread  is  the  appropriate  specialization  of  Digraph.)  This  is  written  in  the  compa 
notation  as  follows. 

IOspec  Thread-find  /  .universc( thread)  .criterion(prcdicate)  =>  .output(object) 
specialization  digraph-find 

Of  course,  computation  types  can  also  be  specialized  by  additional  constraints  between  i 
example,  set  addition  by  side  effect,  #  Set-add,  is  viewed  as  a  specialization  set  addition  in  gener 
expressed  formally  as  follows. 

#sct-add(a)  =  [  set-add(a)  A  old(a)=new(a)  J 

In  other  words,  instances  of  #Sct-add  are  those  instances  of  Set-add  in  which  the  Old  an 
objects  are  identical.  In  tabular  notation,  this  will  be  written  as  follows. 

IOspec  #  Set-add  /  .old(objcct)  .input(object)  =>  .new(object)  specialization  set-add 
postconditions  .old  =  .new 
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Notice  that  the  type  restrictions  on  Old  and  New  above  are  Object  rather  than  Set,  as  in  Set-add. 
This  usage  is  essentially  a  syntactic  trick  to  control  the  abbreviation  that  will  be  applicable  in  the 
postcondition  above.  Logically,  an  Object  restriction  is  weaker  than  a  Set  restriction,  so  no  information  is 
added. 

Extension 

The  basic  idea  of  extension  is  to  define  a  new  type  with  an  additional  role  function,  such  that 
instances  of  the  new  type  have  the  same  constraints  as  the  old  type  between  those  roles  which  are  in 
common.  The  formalization  of  extension  is  more  complicated  than  the  formalization  of  specialization  in 
the  preceding  section.  In  the  case  of  specialization,  the  new  behavior  function  or  predicate  on 
computations  can  be  defined  simply  in  terms  of  the  old  one.  For  extension,  however,  new  cxtcnsionality 
and  comprehension  axioms  need  to  be  written  for  the  new  type.  However,  these  new  axioms  are  related 
to  those  of  the  old  type  in  a  systematic  way. 

A  common  use  of  extension  is  to  add  an  additional  output  to  an  input-output  specification.  For 
example,  when  Thread-find  operations  are  used  in  conjunction  with  other  plans,  such  as  splicing,  it  is 
convenient  to  have  as  output  not  only  the  node  found,  but  also  the  previous  node  in  the  thread.  We  call 
this  extra  role  Previous,  and  the  extended  operation  type  Internal-thrcad-find. 


Table  8-L.  Internal  Thread  Find. 

Axiom  ofExtensionality 

Vct/J  [  [  intemal-thread-find(a)  A  internal-thread-find(/3)  A  in(a)=in(/J)  A  out(a)=out(/J) 

A  universe(a) = universef/? )  A  critcrion(a)=criterion(/J)  A  outputfa) = output(/}) 
A.preyiausfa) = prgvjQpsfl?)  1 
Da=fi] 

Axiom  of  Comprehension 

V  wxyzst  [  [  3a  { thread-find(a)  A  in(a) =s  A  out(a)  =  t 

A  univcrsc(a)=  w  A  criterion(a)  =  x  A  output(o)=>’) 

A  zgmdgfiagd 

A  appl vfnredicatef x.ri.rootf  threadf mri))  =  false 
A  successor thread! w.s).z.v)  1 

*♦  3/3  [  intcmal-thrcad-find(/?)  A  in(/3)=s  A  out(/3)= / 

A  universc(y3)  =  wA  critcrion(/S)=x  A  output()9)=^  A  prcvious(j8)=z]  J 

lOspec  Internal-thrcad-find  /  .universe(thread)  .criterion(prcdicate) 

=>  .output(objcct)  .prcviousfobjcct) 

extension  thread-find 

preconditions  apply(.criterion,root(.univcrsc))  =  false 
postconditions  succcssorf.uni  vcrsc,.previous,.  output) 
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The  axioms  for  Internal-thread- find  are  shown  in  Table  8-L.  They  are  derived  from  the  axioms  of 
Thread-find  by  adding  the  underlined  portions.  In  the  axiom  of  cxtensionality,  an  additional  equality  is 
added  for  the  Previous  role.  The  axiom  of  comprehension  specifies  the  constraints  on  the  new  type  by 
first  referring  to  the  corresponding  instance  of  the  old  type, 

3a  [  thread-find(a)  A  in(a)  =  r  A  .„ } 

and  then  specifying  the  added  underlined  constraints,  which  include  the  type  restriction  on  the  new  role 
and  some  additional  constraints  between  this  role  and  the  others.  One  could  think  of  this  as  an  extension 
step,  followed  by  a  specialization,  but  in  practice  one  almost  never  adds  a  new  role  without  relating  it  to 
the  old  roles.  As  usual  the  more  compact  tabular  notation  is  shown  at  the  bottom  of  the  table. 

8.10  Plans  Involving  Side  Effects 

Given  the  logical  foundations  of  the  plan  calculus  described  in  this  chapter,  it  is  now  possible  to 
explain  a  little  more  about  plans  involving  side  effects.  This  section  has  two  basic  points  to  make.  The 
first  point  is  that,  since  reasoning  about  plans  involving  side  effects  can  in  general  be  quite  difficult,1  the 
inspection  method  approach  is  to  formalize  many  common  forms  of  side  effect  usage  as  plans  and 
overlays  in  the  plan  library  and  use  them  in  the  analysis,  synthesis  and  verification  of  programs  to  bypass 
general  reasoning. 

The  second  basic  point  is  that,  whenever  possible,  plans  in  the  library  are  written  at  a  level  of 
abstraction  which  does  not  make  any  commitment  to  whether  or  not  side  effects  are  used.  TTiis  principle 
is  exemplified  by  the  input-output  specifications  shown  in  Table  8-M.  In  each  case,  the  "impure" 
specification  is  viewed  as  a  specialization  of  the  pure  specification.  For  example,  # Set-add  is  the 
specification  for  adding  a  member  to  a  set  by  side  effect.2 

Table  8-N  and  Fig.  8-6  show  an  example  of  a  very  general  form  of  side  effect  usage  which  can  be 
captured  using  plans  and  overlays.  The  right  hand  side  of  the  overlay  in  Table  8-N  is  the  plan  for 
modifying  a  function  (Updatc.Old)  such  that  all  domain  elements  which  used  to  map  to  a  given  range 
element  (Update. Value)  now  map  to  a  new  clement  (Update.Input),  where  the  new  range  element  is 
computed  from  the  old  range  element  by  the  Action.  For  example,  this  is  the  structure  of  the 
symbol-table-add  procedure  in  Chapter  Two:  a  new  bucket  is  computed  from  an  old  bucket  of  the  table 
by  Set-add;  the  table  (modelled  as  function  from  indices  to  buckets)  is  then  modified  so  that  the  new 
bucket  is  the  new  value  of  the  index  of  the  old  bucket. 

The  overlay  #01d+input+new>action+update  records  the  fact  that  computing  the  new  range 
clement  by  side  effect  obviates  the  step  of  modifying  the  function  itself.  This  is  the  way  the 
symbol -table -delete  procedure  works  (except  for  the  special  case  handled  separately  before  the  loop): 
the  new  bucket  is  computed  from  the  old  bucket  by  side  effect  (splicing  out),  so  that  no  subsequent 


1.  See  Shrobc  (64)  for  an  approach  to  the  explicit  control  of  reasoning  about  plans  involving  side  effects. 

1  Note  that  the  prefix  character "  # "  is  used  to  name  impure  input-output  specifications  as  a  mnemonic  device. 
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Table  8-M.  Impure  Input-Output  Specifications. 

lOspec  old+new  /  .old(object)  =>  .new(object) 

lOspec  #  old+new  /  .old(object)  =>  .new(object)  specialization  old+new 
postconditions  .old = .new 

lOspec  #set-add  /  .old(set)  .input(object)  =>  .new(set) 
specialization  set-add  #  old+new 

lOspec  tfset-remove  /  .old(set)  .input(object)  =>  .new(set) 
specialization  set-remove  #old+new 

lOspec  » restrict  /  .old(set)  .criterion(predicate)  =>  .new(set) 
specialization  restrict  #old+new 

lOspec  #newarg  /  .old( function)  .arg(object)  .input(object)  =>  .new( function) 
specialization  newarg  old+new 

lOspec  jrnewvalue  /  .old( function)  .valuc(object)  .input(object)  =>  .new(function) 
specialization  newvalue  #oId+new 


arravstore  is  required.  Other  specializations  and  extensions  of  #01d+input+ncw  for  which  this 
implementation  works  are  shown  as  properties  of  the  overlay. 
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Table  8-N.  Updating  a  Function  by  Side  Effect 

TemporalOverlay  #old+input+new>action+update:  #old+input+new  -+  #action+update 
properties  V AP[  P=  #old+input+ncw>action+update(/4)  D 

[[instance^ set-add, A)  *-*  instance^  set-add, /’.action)] 

A  [  instance(#set-rcmove,/l)  «-»  instance(# set- remove, /’.action)  ] 

A  ( instance^ newright,/!)  *-*  instance(#nc wright, /’.action)] 

A  [ instancc(#newlcft,/f)  «-*  instance{#newleft, /’.action)] 

A  [  instance^  iniemal-thread-ad<M) «-» instancc(  #  internal-thread-add, /’.action)  ] 
A  [  instance(#intemal-thread-remove,/f) 

*♦  instance^  intemal-thread-remove./’.action)]]  ] 
correspondences  #oId+input+new.old=  #action+update.action.old 
A  #old+input+new.input=  #action+updatc.action.input 
A  #old+input+new.in=  #action+update.action.in 
A  #old+input+new.out=  #action+update.update.out 

TemporalPlan  laction+update 
roles  .action(old+input+new)  .update(#  new  value) 
constraints  .action.old = .update. value  A  .action.output=.update.input 
A  cflow(.action.out,.update.in) 

IOspec  old+input+new  /  .old(objcct)  .input(object)  =>  .new(object)  extension  old+new 

IOspec  #o)d+input+new  /  .old(object)  .input(object)  =»  .new(object) 
extension  #old+new 
specialization  old+input+new 
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CHAPTER  NINE 

LOOPS  AND  TEMPORAL  ABSTRACTION 


9.1  Introduction 

The  plan  calculus  uses  self-referential  (i.e.  recursive)  definitions  to  represent  unbounded  structures. 
This  chapter  concentrates  on  the  special  case  of  singly  recursive  plans,  and  loops  in  particular.  The 
generalization  of  these  ideas  to  multiple  recursion  will  be  discussed  briefly  at  the  end  of  the  chapter. 

Wc  begin  in  Table  9- A  with  a  minimal  plan.  Single- recursion,  which  says  nothing  more  than  that 
there  is  a  role.  Tail,  constrained  to  be  either  Nil  or  itself  a  Single-recursion.  A  finite  single  recursion  is 
defined  as  one  whose  tail  is  Nil  or  eventually  has  a  Nil  tail.  "Eventually"  is  defined  by  the  transitive 
closure  tail  relation.  Tail*,  which  is  in  turn  defined  in  terms  of  the  n-th  tail  relation,  Tailn. 

The  most  common  singly  recursive  data  plan.  List,  has  already  been  discussed  in  Chapter  Eight 
The  next  section  in  this  chapter  will  concentrate  on  how  loops,  the  most  common  singly  recursive 
temporal  plans,  are  represented  in  the  plan  calculus.  The  section  following  then  shows  how  to  represent 
the  relationship  between  singly  recursive  temporal  plans  (loops)  and  and  singly  recursive  data  plans  (lists) 
using  overlays.  Finally,  note  that  the  taxonomy  of  loops  discussed  in  this  chapter  covers  only  loops  with  a 
single  jump  from  the  end  of  the  loop  to  the  beginning  (i.e.  interleaved  loops  are  not  included). 


Table  9-A.  Single  Recursion. 

DataPlan  single-recursion 
roles  .tail(singlc-recursion+nil) 

Type  singlc-recursion+nil  uniontype  single- recursion  nil 

DataPlan  finitc-single-rccursion  specialization  single-recursion 
roles  .taiKsingle-recursion+nil) 
constraints  .tail = nil  v  3x  [  tail*(.tail) = x  A  x= nil  ] 

Function  tail*:  single-recursion  -►  object 
properties  VR  [  instancc(singlc-rccursion,tail*(K))  v  tail*(/?)= nil  ] 
definition  x- tail*(/?)  s  [  3 n  tailn(n,/?)  =  jr) 

Rinfunction  tailn:  natural  X  single-recursion  -*  singlc-recursion+nil 
definition  x  =  tailn(n,R)  s  [  |  n=  1  A  jr=  /f.tail  ]  v  x = tailn(oncminus(n),/?.tail)  ] 
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9.2  Loops 


Since  the  temporal  order  relation  on  situations  (Precedes)  is  not  allowed  to  have  any  cycles,  loops 
are  represented  in  the  plan  calculus  as  singly  recursive  plans  where  the  jump  from  the  end  of  the  loop  to 
the  beginning  is  viewed  as  a  recursive  invocation.  For  example.  Fig.  9-1  is  the  plan  diagram  for  the 
searchlist  program  below. 


(DEFINE  SEARCHLIST 
(LAMBDA  (L  P) 

(PROG  (ENTRY) 

'  LP  (SETQ  ENTRY  (CAR  L)) 

(COND  ((FUNCALL  P  ENTRY )( RETURN  ENTRY))) 
(SETQ  L  (CDR  L)) 

(GO  LP)))) 


The  Tail  role,  which  represents  the  recursive  invocation  of  the  loop  body,  is  constrained  to  be  an 
instance  of  the  same  plan  as  the  outside  plan.  This  is  indicated  in  plan  diagrams  by  a  spiral  line  from  the 
outside  plan  box  to  the  recursive  role.  The  operation  boxes  in  the  diagram  are  instances  of  ©Function; 
the  test  boxes  are  instances  of  ©Predicate;  and  the  join  boxes  are  instances  of  Join-output.  Thus  we  are 
viewing  the  program  as  if  it  were  coded  as  follows. 


(DEFINE  SEARCHLIST 
(LAMBDA  (L  P) 
(PROG  (ENTRY) 
(LP)))) 


(DEFINE  LP 
(LAMBDA  () 

(SETQ  ENTRY  (CAR  L)) 

(COND  ((FUNCALL  P  ENTRY) (RETURN  ENTRY))) 

(SETQ  L  (CDR  L)) 

(LP))) 

This  form  of  single  recursion,  in  which  the  recursive  call  is  the  last  step  of  the  program,  is  often 
called  "tail  recursion"  or  "iterative”  single  recursion.  Many  Lisp  interpreters  and  compilers  treat  loops 
and  tail  recursions  as  superficial  syntactic  variations.  For  example,  in  Scheme,  a  dialect  of  Lisp  developed 
by  Sussman  and  Steele  [65],  the  prog  with  go  construction  is  provided  as  a  macro  which  expands  into  a 
single  recursion  similar  to  the  example  above.  The  Scheme  interpreter  executes  tail  recursions  without 
accumulating  stack  depth.  The  compiler  for  Scheme  also  views  looping  constructs  as  macros  which 
expand  into  singly  recursive  structures. 

Given  this  view  of  loops,  it  is  possible  to  formalize  a  small  set  of  the  basic  plans  which  decompose 
many  loops  into  intuitively  meaningful  parts.  The  remainder  of  this  section  will  present  these  plans, 
along  with  explanations  and  some  typical  fragments  of  code  which  are  instances.  The  taxonomy  of  loops 
presented  here  is  an  extension  of  the  work  of  Waters  [73]. 
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Table  9-B.  Iterative  Steady  State  Plans. 

TemporalPlan  iterative-application  extension  single-recursion 
roles  .action(@function)  .tail(itcrative-application) 
constraints  .action.op  =  .tail.action.op  A  cflow(.action.out,.tail.action.in) 

TemporalPlan  iterative-generation  specialization  iterative-application 
roles  .action(@function)  .tail(iterative-generation) 
constraints  .action.output = .  taiLaction.input 

TemporalPlan  iterative-filtering  extension  single-recursion 
roles  .filter(cond)  .tail(iterative-filtcring) 
constraints  instancc(@prcdicate,.filter.if) 

A  .filter.if.criterion = .tail.filtcr.if.criterion 
A  cflow(.filter.end.out,.tail.filter.if.in) 


Steady  State  Plans 

To  begin  let  us  ignore  any  exits  from  a  loop  and  the  question  of  termination.  This  is  what  1  call  the 
"steady  state"  model.  This  viewpoint  will  be  formalized  later  as  an  overlay  which  explicitly  assumes  that 
the  loop  does  not  exit 

One  of  the  most  common  computations  in  a  loop  is  to  repeatedly  apply  a  given  function  (the  same 
function  each  time)  to  the  output  of  the  preceding  application  of  that  function.  This  pattern  of 
application  is  in  general  (i.e.  for  multiple  recursive  plans)  called  generation.  The  special  case  for  loops  is 
called  iterative  generation,  as  shown  in  Table  9-B  and  Fig.  9-2.  Notice  that  the  starting  value  for  the 
generation  is  Action.Input,  the  input  to  the  first  application.  The  searchlist  example  contains  an 
instance  of  Iterative-generation,  as  shown  below,  where  the  function  being  applied  is  Cdr  and  the  variable 
l  holds  the  successive  values  generated. 

(PROG  (...) 

lp  ... 

(SETQ  L  (COR  L)) 

(GO  LP)))) 

Using  setq  this  way  is  the  most  common  way  of  coding  iterative  generation  in  Lisp,  but  there  are 
other  ways  of  achieving  the  necessary  data  flow,  as  illustrated  below. 

(OEFtNE  LP 
(LAMBDA  (L) 

(LP  (COR  L)))) 

A  particularly  common  specialization  of  iterative  generation  is  Counting,  where  the  function 
applied  is  Oncplus  and  the  initial  input  is  1. 
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Figure  9-2.  Iterative  Generation  Plan. 
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TemporalPlan  counting  specialization  iterative-generation 
roles  .action(@function)  .tail(counting) 
constraints  .action.op  =  oncplus  A  .action.input=  1 

The  Iterative-application  plan  shown  in  Table  9-B  and  Fig.  9-3,  captures  the  idea  of  repeatedly 
applying  a  given  function  to  an  input  which  is  generated  by  some  other  part  of  the  loop.  ihe  output  of 
this  application  may  then  be  the  input  to  some  other  repeated  computation.  The  application  role  in  this 
plan  is  also  called  the  Action.1  For  example  in  searchlist,  the  function  car  is  applied  to  current  value  of 
l  to  get  a  new  entry  each  time  around  the  loop. 

(PROG  (L  ENTRY) 

LP  (SETQ  ENTRY  (CAR  L) ) 

(GO  LP)) 

These  two  simple  plans,  Iterative-generation  and  Iterative-application,  together  with  a  number  of 
common  specializations,  such  as  counting  and  CDRing,  form  the  backbone  of  many  common 
computations.  For  example,  we  have  just  analyzed  the  CAR-CDRing  in  searchlist  as  iterative  generation 
and  application.  A  similar  programming  cliche'  is  looping  through  an  array: 

(PROG  (I) 

(SETQ  I  1) 

LP  ... 

...(ARRAYFETCH  A  I)... 

(SETQ  I  (1+  I)) 

(GO  LP) 

•  ••) 

Here  the  iterative  generation  is  counting  and  the  application  is  fetching  from  the  array. 

The  final  iterative  plan  in  Table  9-B  is  Iterative-filtering,  also  shown  in  Fig.  9-4.  Typically  it  is  used 
to  select  some  subset  of  the  values  of  a  loop  variable  for  special  processing,  as  suggested  by  the  following 
code. 


(PROG  (A) 

lp  !!! 

(CONO  ( (P  A)  ...A...)) 

(GO  LP)) 

The  non-recursivc  role  in  this  plan.  Filter,  is  a  conditional  structure  (Cond).  Each  time  around  the 
loop,  a  given  predicate  (the  same  one  each  time)  is  used  to  test  some  object  provided  by  the  rest  of  the 
loop.  Based  on  the  result  of  this  test,  either  the  Then  or  the  Else  wings  of  the  conditional  will  be 
executed. 


1.  Iterative-generation  is  in  fact  a  specialization  of  Iterative-application,  as  ran  be  seen  in  Tabic  9-B. 
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Figure  9-4.  iterative  Filtering  Plan. 
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Table  9-C.  Iterative  Termination. 

TemporalPlan  iterative-termination  extension  single-recursion 
roles  .exit(cond)  .tail(iterative-tcrmination+nil) 
constraints  ( .tail  =  nil  «-*  ,cxit.if.succeed*-L  ] 

A  cflow(.exit.if.fail,.lail.cxit.if.in) 

A  cflow(.tail.exiLend.out,.cxitend.fail) 

TemporalPlan  itcrativc-tcrmination-prcdicate  specialization  iterative-termination 
roles  .exit(cond)  .tail(itcrative-tcrmination-prcdicate+nil) 
constraints  instance(©predicate,.exit.if) 

A  .exiLif.criterion  =  ,tail.exit.if.criterion 

TemporalPlan  iterative-termination-output  specialization  iterative-termination 
roles  .exit(cond)  .tailOterative-tcrmination-output+nil) 
constraints  instancc(join-output,.exitend) 

A  .tail.exitend.output= .exit.end.fail-input 

TemporalPlan  itcrative-cotermination  extension  itcrative-termination-predicate 
roles  .exit(cond)  .co-iterand(object)  .tail(iterative-cotermination+nil) 
constraints  .co-iterand*  .exitif.input 

Type  itcrativc-termination+nil  uniontype  iterative-termination  nil 

Type  iterative-termination-prcdicatc+nil  uniontype  iterative-termination-predicate  nil 

Type  iterative-tcrmination-output+nil  uniontype  iterative-termination-output  nil 

Type  iterativc-cotermination+nil  uniontype  itcrative-cotermination  nil 


Let  us  now  consider  loops  that  have  exits.  The  minimal  plan  for  a  loop  with  a  single  exit  is 
Iterative-termination,  shown  in  Table  9-C  and  Fig.  9-5.  This  plan  describes  loops  with  a  single  exit  which 
arc  expected  to  terminate  by  that  exit.  It  is  similar  to  Iterative-filtering  in  that  the  non-recursive  role, 
called  F.xit  here,  is  an  instance  of  Cond.  In  this  plan,  however,  the  recursive  invocation  (Tail)  is 
constrained  to  occur  between  the  test  and  the  join.  The  succeed  case  of  the  test  exits  the  loop  by  bypassing 
the  recursive  invocation;  if  the  exit  test  fails,  then  the  exit  test  of  the  tail  must  occur.  Furthermore,  if  the 
tail  of  the  loop  exits  through  the  end  join,  the  whole  loop  ends.  These  control  flow  constraints,  together 
with  the  constraints  of  Cond,  prohibit  other  exits  from  the  loop  and  require  that  the  loop  eventually 
terminates,  i.e.  it  follows  from  the  constraints  on  Iterative-termination  that 


cflow(.cxit.if.in,.cxiLcnd.out) . 
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Table  9-D.  Steady  State  Model 

TemporalPlan  iterative-stcady-state  extension  single-recursion 
roles  .step  (situation)  .tail(iterative-steady-state) 
constraints  cflow(.step,.tail.step) 

TemporalOverlay  iterativc-tcrmination>steady-state :  iterative-termination  -»  iterative-steady-state 
correspondences 

iterative-tcrmination.exitif.in  =  iterative-steady-statejtep 

A  iterative-termination  >steady-state(iterative-tennination.tail) = iterati vc-steady-state.tail 


Given  an  instance  of  Iterative-termination,  the  exit  can  be  ignored  for  the  purpose  of  steady  state 
analysis  by  assuming  that  the  exit  test  always  fails.  This  modelling  assumption  is  formalized  by  the 
overlay  shown  in  Table  9-D.  The  Iterative-steady-state  plan  is  introduced  to  represent  a  non-terminating 
loop,  Le.  there  is  control  flow  from  each  Step  of  the  iteration  to  the  next.  According  to  the  overlay 
lterative-termination>steady-state,  an  instance  of  Iterative-termination  is  viewed  as  an  instance  of 
Iterative-steady-state  in  which  the  current  Step  corresponds  to  the  input  situation  of  the  exit  test  The 
control  flow  constraint  in  the  Iterative-steady-state  plan  thus  amounts  to  assuming  the  exit  test  always 
fails. 

The  two  specializations  of  Iterative-termination  in  Table  9-C  concern  what  kind  of  test  is  performed 
and  whether  a  final  value  is  available  as  an  output  of  the  loop.  Iterative-termination-predicate  is  the  plan 
for  the  common  case  of  loops  where  the  exit  tests  a  unary  predicate  that  does  not  change  as  the 
computation  proceeds.  Itcrative-termination-output  is  a  fragment  (used  to  build  up  other  plans)  which 
expresses  the  pattern  of  data  flow  needed  in  a  loop  to  make  the  final  value  of  some  iterand  available  as  an 
output  of  the  entire  loop  when  it  is  done.  For  such  loops,  the  F.nd  join  is  an  instance  of  Join-output,  and 
the  failure  case  of  each  join  has  data  flow  from  the  output  of  the  F.nd  join  of  the  tail.  The  final  plan  in 
this  table,  Itcrative-cotermination,  is  also  a  fragment  used  to  build  up  other  plans.  In  this  case,  a  Co- 
itcrand  role  is  added  to  Iterative-termination-predicate,  which  identifies  an  object  of  interest  in  the  loop 
other  than  the  input  to  the  test. 

Given  these  fragments,  Iterative-search,  shown  in  Table  9-E  and  Fig.  9-6,  can  be  defined  simply  as  a 
specialization  of  both  Itcrativc-termination-prcdicate  and  Iterative-termination  output  The  only 
additional  constraint  added  to  express  the  idea  of  a  search  loop  is  that  the  output  object  is  the  final  object 
that  satisfied  the  predicate  of  the  exit  test.  For  example,  in  the  searchlist  program  the  value  of  entry  on 
the  last  repetition  is  returned. 

(PROG  (ENTRY) 

IP  ... 

(COND  ((FUNCALL  P  ENTRY) (RETURN  ENTRY))) 

(GO  IP)) 
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Table  9-E.  Iterative  Search. 

TemporalPlan  iterative-search 

specialization  iterative-tcrmination-predicate  iterative-termination-output 
roles  .cxit(cond)  .tail(iterative-search+nil) 
constraints  .exit.if.input = .exitenAsucceed-input 

TemporalPlan  iterative-coscarch  specialization  iterative-cotermination 
extension  iterative-termination-output 
roles  .exit(cond)  .co-iterand(object)  .tail(iterative-cosearch+nil) 
constraints  xo-iterand  ifin = .exiLcn  Asucceed-input 

Type  itcrative-search+nil  j miontype  iterative-search  nil 

Type  iterative-cosearch+nil  uniontype  iterative-cosearch  nil 


A  closely  related  kind  of  search  loop  is  one  in  which  the  object  returned  is  not  the  same  as  the 
object  tested  in  the  exit  test,  as  for  example  the  program  below,  which  calculates  the  length  of  a  Lisp  list 


(DEFINE  LENGTH 
(LAMBDA  (L) 

(PROG  (N) 

(SETQ  N  0) 

LP  (COND  ((NULL  i)(RETURN  g))) 
(SETQ  L  (CDR  L) ) 

(SETQ  N  (1+  M) ) 

(GO  LP)))) 


Here  consecutive  values  of  l  (generated  by  cdr)  are  tested  by  null,  while  at  the  same  time  n  is 
counting.  When  the  null  test  finally  succeeds,  the  current  value  of  n  is  returned  as  the  output  of  the  loop. 
This  pattern  of  loop  termination  is  formalized  as  the  Iterative-cosearch  plan  shown  in  Table  9-E  This 
plan  is  a  specialization  of  Iterative-cotermination  and  an  extension  of  Iterative-termination-output 
(adding  the  Co-iterand  role),  in  which  the  output  object  is  constrained  to  be  the  final  co-itcrand  when  the 
loop  exits. 

A  third  basic  loop  plan  which  returns  an  output  is  Iterative-accumulation,  shown  in  Table  9-F  and 
Fig.  9-7.  On  each  repetition  of  an  accumulation  loop,  an  operation  (Add)  is  performed  which  takes  an 
Old  object  and  another  input,  and  returns  a  New  object  of  the  same  type.  Set-add  and  Push  are  examples 


Table  9-F.  Iterative  Accumulation. 

TemporalPlan  iterative-accumulation  extension  itcrative-termination-output 
roles  .cxit(cond)  .init(objcct)  .add(cld+input+ncw)  .tail(  iterative-accumulation) 
constraints  .init = .add.old  A  .init  =  .exit.cnd.succccd-input 
A  .add.new  =  .lail.init  A  cflow(.cxil.if.fail,ndd.in) 

A  cflow(.add.out,.tail.exit.if.in)  A  A  cflow(.tail.cnd.out,.end.fail) 
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of  such  operations  for  sets  and  lists.  The  Old  input  on  the  first  repetition  is  called  the  Init;  on  successive 
repetitions  of  the  loop,  the  Old  input  of  each  Add  is  the  same  as  the  New  output  of  the  previous  Add. 
The  Input  of  Add  on  each  repetition  is  provided  from  the  rest  of  the  loop.  For  example,  the  following  is 
code  for  a  typical  accumulation  loop. 

(PROS  (ACCUM  ...) 

(SETQ  ACCUM  ...) 

LP  (COMO  ( ( . . . )(RETURN  ACCUM))) 

(SETQ  ACCUM  (CONS  ...  ACCUM)) 

(GO  LP)) 

Here  the  Add  operations  are  instances  of  Push  (implemented  as  cons  for  Lisp  lists).  The  value  of 
accum  returned  from  the  loop  (Exit-End.Output)  is  the  same  as  the  New  output  of  the  last  Push,  except 
when  the  loop  exits  the  first  time,  when  the  value  of  accum  is  determined  by  the  initial  setq  (Init). 

Specializations  of  Iterative-accumulation  for  different  types  of  Add  and  Init  correspond  to  common 
programming  cliche’.  If  the  Add  roles  are  filled  by  instances  of  Push  and  the  Init  is  Nil,  then  we  are 
accumulating  the  Input’s  as  a  list.  If  the  Add  roles  are  filled  by  instances  of  Set-add  and  the  Init  is  an 
empty  set,  then  we  are  accumulating  the  Input’s  as  a  set  Applications  of  Plus  and  Times  can  also  be 
viewed  as  instances  of  Old+input+new.1  With  appropriate  Init’s,  0  and  1  respectively,  these  accumulation 
loops  compute  the  sum  and  product  of  the  Input’s.  These  ideas  about  accumulation  will  be  formalized 
further  later  in  this  chapter. 


Table  9-G.  Two  Exit  Loops. 

TemporalPlan  cascade-iterative-termination  extension  single-recursion 
roles  .if-onc(tcst)  .if-two(tcst)  .cnd-onc(join)  .end-two(join) 

.tail(cascadc-iterativc-termination) 

constraints  cflow(.if-one.fail,.if-two.in)  A  cflow(.if-one.succeed,.end-one.succeed) 

A  cflow(.if-two.fail,.tail.if-one.in)  A  cflow(.if-two.succccd,.end-two.succeed) 

A  cflow(.tail.end-one.out,.end-onc.fail)  A  cflow(.taiI.end-two.out,.end-two.fail) 

A  (.tail = nil  «-*  (.if-one.succccd*±  v  .if-two.succeed*  -L)) 

A  (.if-one.in*  _L  ♦*  (.cnd-onc.out*_L  v  .cnd-two.out*.!)) 

TemporalOverlay  cascadoitcrativc-tcrmination: 

cascadc-iterativc-termination  -*  iterative-termination 

correspondences 

cascadc-itcrativc-tcrmination.if-onc = iterative-tcrmination.exit.if 
A  cascadc-itcrativc-termination.cnd-onc  =  iterativc-tcrmination.cxiLend 
A  cascadoitcrativc-tcrmination(cascadc-iterative-tcrmination.tail)  =  itcrativc-tcrmination.laiI 


1.  See  overlay  (^Binfuneiion^d  +  inpul  +  new  in  (he  appendix. 
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The  minimal  plan  for  two  exits  from  a  loop  is  Cascadc-itcrative-termination  shown  in  Table  9-G 
and  Fig.  9-8.  For  example,  the  loop  in  the  lookup  procedure  of  Chapter  Five  had  two  exits  as  shown 
below. 


(PROG  (...) 

LP  (COND  (  ...  (RETURN  ...))) 

(COND  (...  (RETURN  ...))) 

(GO  LP)) 

The  plan  for  this  code  has  two  tests,  If-one  and  If-two,  and  two  corresponding  joins,  End-one  and 
End-two.  Each  time  around  the  loop,  If-one  is  performed  first;  if  it  fails,  then  If-two  is  performed.  If  the 
second  test  fails,  the  loop  is  repeated.  If  either  test  succeeds,  the  loop  is  terminated  by  control  flow  to  the 
corresponding  join  which  bypasses  the  recursive  invocation  (Tail).  The  final  constraint  on  Cascade- 
itcrative-termination  says  that  if  the  input  situation  of  the  first  test  occurs,  then  one  of  the  output 
situations  of  the  joins  will  occur.  This  means  that  the  loop  is  expected  to  eventually  terminate  on  one  of 
its  exits. 

Steady  state  analysis  of  two  exit  loops  is  achieved  in  two  steps.  First  a  two  exit  loop  is  viewed  as  a 
single  exit  loop  by  assuming  the  second  exit  is  never  taken  (using  the  overlay  Cascadoiterative- 
termination  in  Table  9-G).  The  first  exit  can  then  be  ignored  using  the  Iterative-tcrmination>stcady-state 
overlay  defined  earlier,  as  for  any  other  single  exit  loop. 

These  few  basic  patterns  of  iterative  computation,  termination,  application,  generation, 
accumulation  and  filtering  appear  over  and  over  again  in  routine  programming.  In  fact,  many  recursive 
programs  are  built  out  of  nothing  but  these  plans.  Waters  [73]  did  an  analysis  of  44  programs  chosen  at 
random  from  the  220  programs  which  comprise  the  IBM  Fortran  Scientific  Subroutine  Package.  All  of 
the  164  loops  contained  in  these  programs  could  be  analyzed  solely  in  terms  of  these  basic  patterns.1 
Furthermore,  most  of  these  were  instances  of  a  small  number  of  common  specializations  of  the  basic 
plans.  Out  of  a  total  of  370  instances  of  generation  and  accumulation,  82  percent  were  either  summation, 
product  aggregation,  maximum,  minimum,  or  counting.2  Out  of  a  total  of  186  loop  exit  tests,  89  percent 
were  simple  comparisons  with  a  fixed  number.3 

Given  that  we  have  identified  instances  of  these  standard  recursive  plans  in  a  program,  the  question 
remains  of  how  to  represent  the  connection  between,  say,  an  generation  and  an  application.  Temporally, 
the  components  of  each  arc  interleaved,  but  it  seems  more  logical  to  view  the  generation  and  application 
as  being  composed  in  some  way.  The  next  section  shows  how  to  formalize  this  viewpoint 


1.  Several  loops  had  more  than  two  exits,  but  this  is  a  straightforward  generalisation  of  the  one  and  two  exit  plans  presented  here. 

2.  Waters’  analysis  docs  not  distinguish  between  generation  and  accumulation.  They  arc  both  categorized  as  augmentations 
(application  of  a  function  or  binary  function)  with  feedback. 

3.  Ihe  input  being  tested  in  most  of  these  exit  tcsLs  was  a  simple  sequence  of  numbers,  most  often  just  counting  up  from  one.  Thus 
for  most  of  these  loops  termination  is  obvious.  This  is  typical  of  routine  programming  —  in  most  cases  the  question  of  termination 
is  settled  by  recognition  of  well-known  patterns. 


I 
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9.3  Temporal  Abstraction 

The  basic  idea  of  temporal  abstraction  is  to  view  all  the  objects  which  fill  a  given  role  in  a  recursive 
temporal  plan  as  a  single  data  structure.1  In  terms  of  Lisp  code,  this  often  corresponds  to  having  an 
explicit  represenu.aon  for  the  history  of  values  taken  on  by  a  particular  variable  at  a  particular  point  in  a 
loop  or  other  recursive  program.  For  example,  in  the  example  program  for  searching  a  list  introduced 
earlier,  we  would  like  to  talk  about  the  values  of  u  at  the  underlined  point  each  time  around  the  loop. 

(DEFINE  SEARCHLIST 
( LAMBDA  (L  P) 

(PROG  (ENTRY) 

LP  (SETQ  ENTRY  (CAR  L)) 

(C0ND  ( ( f UNCALL  P  ENTRY)(RETURN  ENTRY))) 

(SETQ  L  (CDR  R)) 

(GO  LP)))) 

In  general,  temporal  abstraction  gives  rise  to  tree  structures.  In  this  section,  however,  we  will 
discuss  only  loops,  which  give  rise  to  linear  structures.  Temporal  abstraction  is  formalized  using  overlays. 
The  left  side  of  such  an  overlay  is  a  recursive  temporal  plan;  the  right  side  is  a  recursive  data  plan  of  the 
same  order  (i.e.  they  are  both  singly  recursive,  or  doubly,  etc.).  The  definition  of  the  overlay  establishes  a 
correspondence  between  roles  in  the  recursive  temporal  plan  and  roles  in  the  data  plan,  such  that  the  time 
behavior  of  a  computation  which  is  an  instance  of  the  plan  on  the  left  is  abstracted  as  a  data  structure 
which  is  an  instance  of  the  plan  on  the  right 

Stream  Overlays 

In  the  case  of  loops,  temporal  abstraction  amounts  to  thinking  of  a  program  in  terms  of  streams. 
Streams  at  particular  points  in  a  loop  are  chosen  for  temporal  abstraction  based  the  analysis  of  the  loop 
according  the  taxonomy  of  iterative  temporal  plans  (generation,  application,  filtering,  etc.)  introduced 
earlier.  For  example,  the  temporal  abstraction  of  the  underlined  values  of  l  in  the  searchlist  program 
above  is  the  stream  of  objects  generated  by  iterative  cdr  generation.  The  overlay  below  and  in  Fig.  9-9 
shows  how  to  express  this  abstraction  formally. 

TemporalOvcrlay  generation-stream :  iterative-generation  -*  list 
correspondences  iterative-gcneration.action,input=  listhead 
A  gencration-stream(iterative-generation.tail)= listtail 

The  head  of  the  list  corresponds  to  the  input  of  the  action  of  the  iterative  generation;  the  tail  of  the 
list  is  recursively  defined  as  the  temporal  abstraction  of  the  tail  of  the  generation. 

We  next  discuss  how  to  abstract  the  temporal  behavior  of  Iterative-application.  For  example,  we 
would  like  to  express  the  relationship  in  the  code  below  between  the  values  of  l  and  the  values  of  entry  at 
the  underlined  points  each  time  around  the  loop. 


1.  Both  Shrobc  [64]  and  Waters  [73]  use  the  idea  of  temporal  abstraction,  but  with  slightly  difTcrcnt  formalizations  than  presented 
here. 


/ 
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(DEFINE  SEARCHLIST 
(LAMBDA  (L  P) 

(PROG  (ENTRY) 

IP  (SETQ  ENTRY  (CAR  i) ) 

(COND  ( (f  JNCALL  P  ENTRY)(RETURN  ENTRY))) 

(SETQ  L  (COR  L)) 

(GO  LP)))) 

This  is  achieved  by  defining  two  overlays,  shown  in  Tabic  9-H  and  Fig.  9-10,  which  temporally 
abstract  the  input  and  output  roles  of  the  Action  of  the  iterative  application.  The  relationship  between 
these  two  streams  is  then  most  conveniently  expressed  by  viewing  them  as  sequences,  as  explained  in  the 
next  section. 

Temporal  Sequences 

Streams  viewed  as  sequences  are  called  temporal  sequences.  Malting  this  abstraction  step  allows  us 
to  use  the  input-output  specifications  on  sequences  to  describe  the  relationship  between  changing  values 
in  loops.  In  particular,  iterative  application  can  be  thought  of  as  implementing  a  Map  operation  from  the 
stream  of  inputs  of  the  Action  role  (viewed  as  a  sequence)  to  the  stream  of  outputs.  This  is  expressed  as 
the  Temporal-map  overlay  shown  in  Table  9-1  and  in  Fig.  9-11. 

On  the  right  side  of  this  overlay  is  the  Map  plan.  The  inputs  to  the  Action  of  the  iterative 
application  (e.g.  the  values  of  l  above)  are  abstracted  as  the  input  to  Map.  The  outputs  of  the  Action  (c.g. 
the  values  of  entry  above)  arc  modelled  as  the  output  of  Map.  The  Op  of  Map  corresponds  to  the  Op  of 
the  Action.  What  w>c  arc  doing  in  this  overlay  is  modelling  the  time  behavior  of  die  recursive  temporal 
plan  on  the  left  as  a  single  step  in  some  other  lime  domain  represented  on  the  right. 

Iterative  generation  can  be  similarly  abstracted  as  an  Iterate  operation,  as  shown  in  Table  9-1.  The 
input  to  the  operation  is  an  iterator  whose  Op  is  the  Op  of  the  Action  of  the  generation  (viewed  as  a 
relation)  and  whose  Seed  is  the  initial  Input  (according  to  the  Temporal-iterator  overlay).  The  output 
sequence  is  the  generated  stream,  as  defined  in  the  preceding  section,  viewed  as  a  sequence. 

Finally,  note  the  following  property  of  Generation-stream  which  tics  together  two  different 
viewpoints  on  generation  loops  that  have  been  introduced  in  this  chapter:  if  a  generation  loop,  viewed  as 
an  iterator,  generates  a  thread,  then  the  temporally  abstracted  (irredundant)  list  of  inputs  to  the  action  of 
that  loop,  viewed  as  a  thread,  is  the  same  thread  as  generated  by  the  iterator. 


Table  9-H.  Application  Stream  Overlays. 

Te/npora/Over%  application-in-stream:  iterative-application  -» list 
correspondences  itcrative-applicatiomaction. input  =  lisLhead 

A  application-in-strcam(itcrativc-appIication.tail)=  listtail 

TemporalOverlay  application-out-stream:  iterative-application  -*  list 
correspondences  itcrative-application.action.output  =  list.head 

A  application-out-strcam(itcrativc-application.tail)=lisLtail 


Applfc»,U&n-t.v\~  s-ffeavA. 


Figure  9-10.  Stream  Abstractions  of  Iterative  Application 


Figure  9-11.  Temporal  Overlays  for  Application  and  Generation. 
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Table  9-1.  Temporal  Sequence  Overlays. 

TemporalOverlay temporal-map:  iterative-application  -*  map 
correspondences 

iterative-application.action.op  =  map.op 

A  list>sequencc(application-in-strcam(  iterative-application)) = map.input 
A  list>scquence(application-out-stream(iterative-application))  =  map.output 

TemporalOverlay  tcmporal-iterate :  iterative-generation  -*  iterate 
correspondences 

temporal-iterator(iterative-generation) = iterate.input 
A  list>sequence(gcneration-stream(iterative-gcneration)) = iterate.output 
A  iterative-generation.action.in  =  iterate.in 

TemporalOverlay  temporal-iterator :  iterative-generation  -*•  iterator 
correspondences  iterativc-gcneration.action.input= itcrator.seed 

A  function>binrcl(iterative-gencration.action.op)= iterator.op 


TemporalOverlay  generation-stream:  iterative-generation  -*  list 
properties  V  /  [  instance!  thread,gencrator>  digraph! temporal-iterator! I))) 

D  Vs  list>thrcad(gcncration-strcam(/),s)  =  gencrator>digraph(  temporal-iterator! /),/.action.in)] 

Temporal  Data  Flow 

In  this  section  we  further  develop  the  notion  of  stream  overlays  in  order  to  specify  the  connection 
between  the  temporal  abstractions  of  different  parts  of  a  loop.  For  example,  in  the  se  archlist  example, 
shown  again  below,  the  stream  generated  by  the  iterative  cdr  generation  is  the  same  as  the  input  stream  to 
the  iterative  CAR  application. 

(DEFINE  SEARCHLIST 
(LAMBDA  (L  P) 

(PROG  (ENTRY) 

LP  (SETO  ENTRY  (CAR  JJ) 

(COND  ((FUNCAtl  P  ENTRY)(RETURN  ENTRY))) 

(SETQ  L  (CDR  JJ) 

(GO  LP)))) 

This  means  that  data  flow  between  operations  in  the  recursive  view  implies  data  flow  between 
operations  in  the  temporally  abstracted  view. 

For  example.  Fig.  9-12  shows  the  temporal  sequence  analysis  of  searchlist.  On  the  left  is  the 
unanaly/.cd  recursive  computation.  As  has  been  pointed  out  before,  this  diagram  contains  an  instance  of 
Iterative-generation  (the  Action  role  corresponds  to  role  Two  of  the  surface  plan),  of  Iterative-application 
(the  Action  role  corresponds  to  role  One  of  the  surface  plan),  and  of  Iterative-search  (the  F.xit.lf  role 
corresponds  to  the  If  role  of  the  surface  plan).  The  right  side  of  the  figure  shows  the  plan  after 
recognizing  these  iterative  patterns  and  applying  the  Temporal-itcratc,  Temporal-map,  and  Temporal- 
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earliest  overlays.1  Temporal  sequence  abstractions  are  labelled.  The  objects  generated  by  cdr  are 
temporally  abstracted  as  the  output  sequence  of  One  (Iterate)  on  the  right.  Furthermore,  since  the  input 
to  the  Action  of  the  generation  on  each  repetition  is  the  same  as  the  input  to  the  Car  application,  this 
sequence  is  therefore  also  the  temporal  abstraction  of  the  inputs  to  the  iterative  application.  Similarly, 
data  flow  between  the  output  of  the  Action  of  iterative  application  and  the  input  to  the  exit  test  of 
iterative  search  on  each  repetition  in  the  surface  plan  implies  data  flow  from  the  output  of  the  Two  (Map) 
to  the  input  of  Three  (Earliest)  in  the  temporal  view. 

Thus  we  see  that  temporal  analysis  leads  to  a  viewpoint  on  loops  in  which  there  are  producers, 
transducers  and  consumers  of  streams.  An  overlay  like  Tcmporal-iterate  models  a  part  of  a  loop  which 
produces  a  stream;  Temporal-map  models  a  part  of  a  loop  which  consumes  one  stream  and  produces 
another  (i.c.  a  transducer);  and  Temporal-earliest  models  a  stream  consumer. 

The  pattern  of  Iterate  and  Map  in  searchlist  (particularly  implemented  temporally  as  iterative 
generation  composed  with  application)  is  a  common  one.  This  plan  is  called  List-generation,  as  shown  in 
Table  9-J,  because  the  output  sequence  of  the  Map  operation  (role  Two),  viewed  as  a  list,  is  the  same  as 
the  labelled  thread  whose  spine  is  generated  by  the  input  to  the  Iterate  operation,  and  whose  label  is  the 


Tabic  9-J.  List  Generation. 

TemporalPlan  list-generation 
properties  V  P  [  instanccflist-gcneration,/*)  D 

Vslist>scquencc(gencration>list(/>),s)=sequence(/).two.output,/>.two.out)] 
roles  .onc(itcratc)  .two(map) 

constraints  .one.output= .two.input  A  cflow(.one.out,.two.in) 

TemporalOverlay  gcnerationMist :  list-generation  -*  list 
definition  Z,  =  gcncration>list(/1)  = 

3T(  instancc(labclled-thread,7) 

A  digraph!  7".spinc,/,.onc.in)=gcnerator>digraph(/>.onc.input,/>.one.in) 

A  function(7’.labcl,7’.two.out)= function(/>.two.op,/*.two.out)  ] 

TemporalPlan  car+cdr  specialization  list-generation 
properties  V P  [  instancefcar+cdr,/*)  D  dotted-pair>list(/>.one.inpuLseed,P.one.in) =gencration>list(/,)  ] 
roles  .onc(itcrate)  .two(map) 

constraints  instancc(cdr-itcrator,.onc.input)  A  ,two.op=car 

DataPlan  cdr-itcrator  specialization  iterator 
roles  .sccd(dottcd-pair)  ,op(manyto-one) 
constraints  .op  =  function>binrel(cdr) 


1.  The  overlay  between  Iterative-search  and  Earliest  will  he  defined  later  in  this  section.  To  simplify  the  presentation,  the  figure 
omits  several  intermediate  analysis  steps. 
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function  applied  in  the  Map  operation.  This  relationship  is  expressed  by  the  overlay  Generation>list,  also 
shown  in  Table  9-J. 

Car+cdr  is  the  common  special  case  of  Lisp  list  generation,  wherein  the  input  to  Iterate  is  an 
instance  of  Cdr-iterator  (an  iterator  in  which  the  Op  is  Cdr)  and  the  function  applied  by  Map  is  Car.  It 
thus  follows  that  the  list  generated  by  Car+cdr,  according  to  the  overlay  Generation  >list,  is  the  same  as  the 
list  implemented  by  the  dotted  pair  which  is  the  seed  of  the  iterator  input  to  Iterate,  according  to  the 
overlay  Dotted-pair>lisL 

Termination 

We  move  on  now  to  the  temporal  abstraction  of  termination  plans,  in  particular  the  overlays  in 
Table  9-K  and  Kg.  9-13,  which  express  how  to  view  the  inputs  to  the  exit  test  of  Iterative-tcrmination- 
predicate  as  a  finite  list 

The  basic  form  of  the  Termination-in-stream  overlay  is  the  same  as  Application-in-stream,  i.e.  the 
head  of  the  list  is  the  input  on  the  first  repetition  and  the  tail  of  the  list  is  defined  recursively.  In  this 
overlay  however,  the  recursive  definition  is  split  into  two  cases:1  if  the  exit  test  succeeds,  then  the  tail  of 
the  list  is  Nil;  if  it  fails,  then  the  tail  of  the  list  is  the  temporal  abstraction  of  the  tail  of  the  termination 
plan.  This  means  that  the  temporal  abstraction  of  the  inputs  to  a  termination  which  exits  on  the  first  step 


Table  9-K.  Termination  Stream  Overlays. 

TemporalOverlay  termination-in-stream :  iterative-termination-predicate  -*•  finite-list 
correspondences 

iterativc-tcrmination-prcdicate.exiLif.input = finite-list.head 
A  (if  iterative-termination-predicate.tail  =  nil 
then  nil 

e/setermination-in-stream(iterative-tcrmination-predicate.tail)) 

=  finite-list,  tail 

TemporalOverlay  termination-fail-strcam :  iterative-termination-predicate  -*  finite-list+nil 
definition  1= tcrmination-fail-stream(T)  & 

V  s  l  list>sequcnce(  L,s) = bu  tlast(  termination-in-stream(  7))  J 

TemporalOverlay  steady-state-stream :  iterative-termi nation-predicate  -*  list 
correspondences 

itcrativc-tcrmination-prcdicatc.cxit.if.inpul = IisLhead 

A  stcady-statc-strcam(itcrativc-tcTminaiion>steady-statc(itcrative-tcrmination-prcdicatc.tail)) 

=  list,  tail 


1.  The  standard  abbreviated  form  A=((/‘X  thcnY  elseZ)  expands  into  [  XDA=Y  J  A  [  ~OOA=Z  1 


/ 
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Figure  9-J3.  Stream  Abstractions  of  Iterative  Termination 
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is  a  singleton  list  (one  with  a  Nil  tail),  and  that  for  all  uses  of  Termination-in-stream  the  last  object  in  the 
list  (i.e.  the  head  of  the  sublist  with  the  Nil  tail)  satisfies  the  exit  predicate. 

Termination-fail-strcam  is  the  overlay  which  abstracts  the  inputs  to  the  exit  test  of  a  loop  as  seen  in 
an  environment  where  the  test  is  known  to  have  failed.  For  example,  the  difference  between 
Tcrmination-in-strcam  and  Termination-fail-stream  is  the  difference  between  the  stream  of  values  of  i 
seen  at  the  first  underlined  point  below  versus  the  second. 

(PROG  (L) 

lp 

(COND  ( ( P  L)(RETURN  ...))) 

. .  4. . . 

(GO  LP)) 

The  Termination-fail  stream  is  defined  in  terms  of  the  Termination-in  stream.  It  is  the  same  as  the 
Termination-in  stream,  except  one  term  shorter  (this  is  expressed  formally  in  terms  of  sequences  and  the 
Butlast  function). 

Like  Iterative-application,  Iterativc-terminaticn-predicate  describes  a  fragment  of  a  loop  which  has 
some  of  its  inputs  provided  by  other  parts  of  the  loop.  The  relationship  between  a  termination  test  and 
the  other  parts  of  the  loop  is  most  conveniently  expressed  in  terms  of  the  relationship  between  the 
Termination-in  or  Termination-fail  streams  and  the  stream  of  inputs  to  the  test  in  the  steady  state  analysis 
(sec  Table  9-D)  The  stream  of  inputs  to  the  test  in  the  steady  state  analysis  is  specified  by  the  overlay 
Stcady-statc-stream  in  Table  9-K.  It  has  a  recursive  definition  similar  to  the  other  stream  overlays  for 
iterative  termination.  In  this  case,  however,  we  are  talking  about  the  stream  of  inputs  which  would  be 
seen  in  the  input  situation  of  the  exit  test  in  a  non-terminating  loop. 

The  relationship  between  the  steady  state  stream  and  the  Termination-in  and  Termination-fail 
streams  is  most  conveniently  expressed  in  terms  of  Truncate  and  Truncate-inclusive  operations  on 
temporal  sequences.  For  example,  in  the  following  loop  the  temporal  sequence  of  values  of  n  at  the 

underlined  point  under  the  steady  state  assumption  is  1,2,3 .  as  generated  by  Natural-iterator  (an 

iterator  in  which  the  Op  is  Oncplus  and  the  Seed  is  1).  The  effect  of  adding  the  termination  test  is  to 
truncate  this  sequence  at  10  (inclusively  at  the  point  indicated).1 

(PROG  (N) 

(SE1Q  N  1) 

LP  . . ,|, 

(COND  ((*  N  10) (RETURN  ...))) 

(SETQ  N  (1+  N)) 

(CO  LP)) 

The  overlays  in  Table  9-L  formalize  this  analysis.  Let  us  first  consider  Tcmporal-truncate-inclusive 
with  reference  to  Fig.  9-14,  which  shows  its  application  to  the  example  program  above.  On  the  left  is  the 
unanalyzed  surface  plan.  In  the  center  is  the  steady  state  analysis  in  which  an  instance  of  Itcrative- 


I.  In  a  later  section,  an  overlay  will  be  introduced  which  captures  the  relationship  between  using  N  at  the  point  indicated  and  a 
loop  that  checks  for  ( «  N  1 1 )  and  uses  N  after  the  test 
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Figure  9-14.  Counting  Program  at  Various  levels  of  Abstraction. 
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Tabic  9-L,  Temporal  Truncation. 

TemporalOverlay  tcmporal-truncate-inclusivc :  iterative-termination-predicate  -*■  truncate-inclusive 
correspondences 

iterativc-termination-predicate.exit.if.criterion  =  truncatc-inclusive.criterion 
A  list>sequence(steady-statc-strcam(itcrative-termination-predicate)) = truncate.input 
A  list>scquencc(tcrmination-in-stream(iterative-tcrmination-predicate)) 

=  truncate-inclusive.output 

A  iterative-termination-predicate.exit.end.out  =  truncate-indusivc.out 

TemporalOverlay  temporal-truncate :  iterative-termination-predicate  -*  truncate 
correspondences 

itcrative-termination-predicate.exit.if.criterion  =  truncate.criterion 
A  list>sequence(stcady-state-strcam(itcrative-termination-prcdicate))=truncate.input 
A  list>sequence(tennination-fail-stream(iterati ve-termination-prcdicatc» = truncate.output 
A  iterative-termination-predicate.exit.end.out  =  truncate.out 


generation  has  been  recognized.  The  temporal  sequence  generated  by  this  generation  is  abstracted  on  the 
right  as  the  output  of  an  Iterate  operation.  This  sequence  is  then  the  input  to  a  Truncate-inclusive 
operation  whose  output  is  the  sequence  of  values  of  n  actually  seen  temporally  at  the  underlined  point 
Note  that  the  termination  constraint  on  the  Iterative-termination  plan  and  its  specializations  is  consistent 
with  the  precondition  on  Truncate  that  there  exists  a  term  of  the  sequence  which  satisfies  the  given 
criterion.  The  Temporal-truncate  overlay  is  similar  to  Temporal-truncate-inclusive,  except  that  the  input 
sequence  is  the  Termination-fail  sequence,  rather  than  the  Termination-in  sequence. 


Tabic  9-M.  Iterate  and  Truncate. 

TemporalPlan  iterate+truncate 
roles  .one(iterate)  .two(in+out) 
constraints  instancc(irrcdundant-scquencc,.one.output) 

A  [  instancc(truncate,.two)  v  instance! truncatc-inclusive,.two)  J 
A  .one.output=.two.input  A  cflow(.one.out,.two.in) 

TemporalOverlay  iterate+truncatotruncatcd-thread :  iterate+truncate  -*  truncated-thread 
properties  V/7[  T  =  itcrate+truncatc>truncatcd-thrcad(/)  D 
[  { instance!  truncate, /.two) 

D  Vstruncatcd>digraph(7’,i)=scqucnce>lhread(/.two.output,/.two.out)] 

A  [  instance!  truncate- inclusive,  /.two) 

D  Vj  truncated  >digraph-inclusive!7’,r)=: sequence) thread(/.two.output,/.two.out)  J  J 

correspondences 

sequcncc>thread!itcrate+truncatc.onc.output)=truncatcd-thrcad.base 
itcrate+truncatc.two.criterion  =  truncated-lhread.criterion 
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The  pattern  of  Iterate  and  Truncate  shown  in  Fig.  9-14,  particularly  implemented  temporally  as  a 
loop  in  which  the  termination  directly  tests  the  current  value  of  an  iterative  generation,  is  a  common  one. 
The  Iterate+truncate  plan  shown  in  Table  9-M  expresses  this  in  a  data  flow  constraint  between  the  output 
sequence  of  the  Iterate  operation  (One)  and  the  input  sequence  of  the  Truncate(-inclusivc)  operation 
(Two). 

Iterate+truncate  can  be  further  abstracted  as  a  truncated  thread,  as  described  by  the  overlay  in 
Table  9-M.  The  base  of  the  truncated  thread  is  the  irredundant  sequence  output  of  the  Iterate  operation, 
viewed  as  a  thread;  the  criterion  is  the  criterion  of  the  Truncate(-inclusivc)  operation.  Note  the  property 
of  this  overlay,'  which  expresses  the  relation  between  the  sequence  and  directed  graph  views  of  these 
operations.  In  particular,  the  finite  graph  implemented  (inclusively)  by  the  truncated  thread  is  the  same 
as  the  output  of  the  Truncate(-inclusive)  operation,  viewed  as  a  thread. 

Another  temporal  abstraction  involving  termination  is  to  view  an  iterative  search  loop  as  the 
implementation  of  an  Earliest  operation,  as  shown  in  Table  9-N  and  Fig.  9-15.  In  this  overlay,  the  input 
sequence  to  the  Earliest  operation  is  the  steady  state  stream  of  inputs  to  the  test  of  the  iterative  search, 
viewed  as  a  sequence.  The  output  of  the  ending  join  of  the  search  plan  is  the  output  of  the  Earliest 
operation.  Note  that  the  termination  constraint  of  Iterative-search  is  consistent  with  the  precondition  on 
Earliest  which  states  that  there  exists  a  term  of  the  input  sequence  which  satisfies  the  given  criterion. 

Cotermination  loops  arc  temporally  abstracted  using  overlays  similar  to  those  already  presented  for 
termination  loops.  The  overlay  Cotermination-in-stream,  shown  in  Table  9-0  abstracts  the  stream  of  co- 
iterands  seen  before  the  exit  test,  similar  to  Termination-in-stream.  Cotermination-fail-strcam  abstracts 
the  stream  of  co-iterands  seen  in  an  environment  where  the  test  is  known  to  have  failed,  similar  to 
Termination-fail-stream.  Finally,  the  stream  of  co-iterands  in  the  steady  state  is  abstracted  by  the  overlay 
Steady-state-costream. 

Given  these  overlays,  Itcrative-coscarch,  as  in  the  length  program  below,  can  be  modelled  as  the 
temporal  implementation  of  a  Co-carlicst  operation,  as  shown  in  Table  9-P.  The  specifications  of  Co- 
earliest  arc  similar  to  those  of  Earliest.  Co-earliest  takes  as  input  two  sequences  (Input  and  Co-input), 
and  returns  as  output  the  term  of  the  Co-input  sequence  which  corresponds  to  the  term  of  the  Input 
sequence  which  would  be  returned  by  Earliest. 


Table  9-N.  Temporal  Earliest 

TmporalO'verlay  temporal-earliest :  iterative-search  -+■  earliest 
correspondences 

itcrativc-search.cxit.if.criterion  =  carlicsuriterion 
A  list>scqucncc(stcady-sutc-strcam(itcrativc-scarch))=carIiesLinput 
A  itcrati vc-scarch.cxit.cnd.output = carlicstoutput 
A  itcrativc-scarch.cxit.cnd.out = earliestout 
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Table  9-0.  Cotcrmination  Stream  Overlays. 

TemporalOverlay  cotermination-in-stream :  iterative-cotermination  -*  finite-list 
correspondences 

itcrative-cotcrmination.co-itcrand = fmitc-list.head 
A  (if  iterativc-cotcrmination.tail  =  nil 
then  nil 

e/j<?cotcrmination-in-stream(iterativc-cotermination.tail)) 

=  finite-list,  tail 

TemporalOverlay  cotcrmination-fail-strcam :  iterative-cotermination  — »  finite-list+nil 
definition  L  -  cotermination- fail-strcam(  T)  = 

Vslist>sequence(L,s)=butlast(cotcrmination-in-stream(7)) 

TemporalOverlay  steady-statc-costream :  iterative-cotermination  -*■  list 
correspondences 

iterative-cotcrmination.co-iterand  =  lisLhead 

A  steady-state-costream(iterative-termination>steady-state{iterative-cotermination)) 

= list  tail 


Table  9-P.  Temporal  Co-carliest. 

IOspec  co-earlicst  /  .input(sequencc)  .criterion(predicatc)  .co-input(sequence) 

=>  .output(object) 

preconditions  le(lcngth(.input),lcngth(.co-input)) 

A  3;  apply(.criterion,apply(.input,/))=true 
postconditions  3i  { apply(. co-input,/) =. output 

A  apply(.criterion,apply(.input,0) = true 
A  Vj(h(i,i)  d  apply(.criterion,apply(.inputj))= false)] 

TemporalOverlay  tcmporal-co-earlicst :  iterative-coscarch  -*  co-earliest 
correspondences 

iterative-coscarch.exiLif.criterion=co-earliest.criterion 
A  list>scquencc(stcady-state-strcam(itcrative-coscarch))=co-carlicstinput 
A  list>sequcncc(steady-state-costream(iterativc-coscarch))=co-earliesLco-input 
A  itcrative-coscarch.co-itcrand = co-earl iest-output 
A  iterative-coscarch.exit.cnd.out = co-earlicstout 
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(0EFINE  LENGTH 
(LAM80A  (L) 

(PROG  (N) 

(SETQ  N  0) 

LP  (COND  ((NULL  k)(RETURN  N))) 

(SETQ  L  (CDR  L)) 

(SETQ  N  (1+  N) ) 

(GO  LP)))) 

Thus  this  program  can  be  temporally  abstracted  (as  shown  on  the  left  of  Fig.  9-16)  as  two  instances 
of  Iterate,  one  with  a  Cdr-iterator  as  input,  and  one  with  Natural-iterator  as  input,  feeding  into  an 
instance  of  Co-carliest  with  a  criterion  of  Null.  What  this  figure  also  shows  is  how  this  plan  implements 
©Length,  the  computation  of  the  length  of  a  sequence.  If  the  Cdr-iterator  input  on  the  left  hand  side  is 
the  implementation  of  the  spine  of  the  sequence  viewed  as  a  labelled  thread,  then  the  output  of  Co- 
earliest  is  the  length  of  the  sequence. 

The  idea  of  truncating  a  sequence  based  on  the  occurrence  of  a  term  satisfying  a  given  predicate  in 
another  (parallel)  sequence  is  expressed  by  the  Cotruncate  specification  defined  in  Table  9-Q.  This 
specification  is  similar  to  Truncate,  except  that  the  output  sequence  is  some  initial  subsequence  of  a 
second  input  sequence,  Co- input.  Furthermore,  it  follows  from  these  specifications  that  if  an  instance  of 
Truncate  and  of  Cotruncate  have  the  same  Input  sequence  and  Criterion,  the  outputs  arc  the  same  length. 
Cotruncate  is  implemented  temporally  by  Iterative-cotcrmination,  as  shown  in  the  overlay  in  Table  9-Q, 
which  resembles  the  Temporal-truncate  overlay. 


Table  9-Q.  Temporal  Cotruncate. 

lOspec  cotruncate  /  .input(sequencc)  .criterion(predicate)  .co-input(scquence) 

=>  .output(finite-sequence) 

properties  V7C[  [  instance(truncate,7)  A  instancc(cotruncate.C) 

A  7~.input=C.input  A  7’.criterion  =  Ccriterion  A  7jn  =  C.in] 

D  lcngth(scqucncc(  7'.output,7'.out))  =  lcngth(scquencc(C.output,C.out))  ] 
preconditions  le(lcngth(.  input),  lcngth(.co-input)) 

A  3/ apply(.critcrion,apply(.input,/))=true 
postconditions 

V/[indcx(.output,f)  **  V/[lc(/,0  3  apply(.critcrion,appIy(.input,/))= false  ]  ] 

A  V< (index! .output,/)  3  apply(.output,/)=apply(.co-input,/)) 

A  apply(.criterion,apply(.input,oncplus(length(.omput))))=true 

TemporalOverlay  teniporal-cotruncatc :  iterative-cotcrmination  -*  cotruncate 
correspondences 

itcrati  vc-cotermination.cxit.if.critcrion  =  cotruncatc.critcrion 
A  list>scquencc(stcady-state-slream(ilcrativc-cotermination))=cotruncatc.input 
A  lisi>scqucncc(steady-staic-costream(iicrative-cotcrmination))  =  cotruncatc.co-input 
A  list>scqucncc(cotcrmination-faiFstrcam(iteraiivc-cotcrmination))=cotruncatc.output 
A  itcrative-cotcrmination.exit.cnd.out  =  truncate.out 
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Figure  9-16.  Computing  the  length  of  u  Sequence. 
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Table  9-R.  Truncated  List  Generation. 

TemporalPlan  truncated-list-generation  extension  list-generation 
properties  V  P  |  instance! truncatcd-list -generation,/*) 

O  Vs  list>sequencc(tnincated-generation>list(/>),s)= sequence! />.threc.output,/>.three.out)  ] 
roles  .one(iteratc)  .two(map)  .thrcc(cotruncate) 
constraints  .one.output = .threc.input  A  .two.output = .three.co-input 
A  cflow(.two.out,.three.in) 

TemporalOverlay  truncated-gcncration>!ist :  truncated-list-gencration  -»  finite-list 
definition  /.=truncatcd-gencration>list(i>)  s 

3TR  [  instance(labc!lcd-thrcad,7)  A  instance(terminated-thread,/J) 

A  Vs[  r=list>labclled-thread(L,s) 

A  digraph! 7’.spine,s)= truncated>digraph(/?,s) 

A  function(r.label,s)=  function(/>.two.op,/>.two.in) 

A  digraph(fl.base,s)  =  generator>digraph(/>.onc.input,/>.one.in) 

A  predicate! fi.criterion,s) = predicate! />.three.criterion,/\three.in)  ]  ] 


TemporalPlan  car+cdr+null 
specialization  truncated-list-generation 
extension  car+cdr 

properties  V  P  [  instance(car+cdr+null,/>)  3 

dotted-pair>list(/>.onc.inpuLsecd,/>.one.in) = truncated-generation>list(P)  ] 
roles  .one(itcrate)  ,two!map)  .thrcc(eotruncate) 
constraints  .thrce.critcrion = null 


One  of  the  most  common  cliches  in  Lisp  programming,,  i.c.  CDRing  down  a  list  until  null,  using  the 
cars,  can  be  analyzed  as  the  composition  of  an  instance  of  Iterate,  Map,  and  Cotruncate.  The  plan  for 
this  in  general  is  called  Truncatcd-list-generation,  as  shown  in  Table  9-R  and  Fig.  9-17.  This  plan  is  an 
extension  of  List-generation,  discussed  earlier  in  this  section.  Similar  to  List-generation,  the  final  output 
sequence  of  this  plan  (in  this  case  the  output  of  role  Three),  viewed  as  a  list,  is  the  same  as  the  labelled 
thread  whose  spine  is  generated  by  the  input  to  the  Iterate  operation  and  truncated  by  the  criterion  of  the 
Cotruncate  operation,  and  whose  label  is  the  function  applied  in  the  Map  operation.  This  relationship  is 
expressed  by  the  overlay  Truncated-gcneratron>Iist  in  Table  9-R,  and  shown  in  Fig.  9-17. 

The  specialization  of  Truncated-list-gencration  for  Lisp  lists  in  particular,  where  the  iterator 
function  is  Cdr,  the  Map  function  is  Car,  and  the  Cotruncate  predicate  is  Null,  is  called  Car+cdr+null. 

•  (PROG  (L) 

LP  (COND  ((NULL  L)(RETURN  ...))) 

...(CM,  n... 

(SETO  L  (COR  L)) 

(GO  LP)) 


/ 
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Figure  9*17.  Truncated  Ust  Generation. 
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The  output  of  role  Three  (an  instance  of  Cotruncate)  in  the  Car+cdr+null  plan  corresponds  to  the 
sequence  of  values  returned  by  car  at  the  underlined  point  in  the  code  above.  This  sequence,  viewed  as  a 
list,  is  the  same  as  the  list  implemented  by  the  dotted  pair  which  is  the  seed  of  the  iterator  input  to  Iterate, 
according  to  the  overlay  Dotted-pair>lisL 

Temporal  Sets 

In  many  programming  applications,  the  order  in  which  data  is  generated  in  a  loop  or  recursion 
doesn’t  matter.  In  such  cases  it  is  appropriate  to  take  temporal  abstraction  one  step  further  and  talk 
about  the  set  of  objects  which  fill  a  given  role  in  a  recursive  temporal  plan.1  This  abstraction  step  is 
added  to  the  existing  temporal  abstraction  framework  by  using  the  List>set  overlay. 

For  example,  a  generation  loop  can  be  thought  of  as  the  temporal  implementation  of  a  transitive 
closure  operation,  in  which  the  binary  relation  being  closed  is  many-to-one.  The  overlay  between  these 
two  views  is  shown  in  Table  9-S  and  in  Fig.  9-18.  On  the  left  of  the  overlay  is  a  generation  loop;  on  the 
right  is  the  application  of  transitive  closure  to  an  iterator.  The  correspondence  between  the  iterator  input 
and  the  loop  is  the  one  already  specified  by  Temporal-iterator,  i.e.  the  Op  of  the  Action  (viewed  as  a 
relation)  is  the  Op  of  the  iterator,  and  initial  input  to  the  Action  is  the  Seed.  The  output  set  of  the 
transitive  closure  operation  is  the  stream  generated  at  the  input  of  the  Action  (as  formalized  by 
Generation-stream),  viewed  as  a  set 

Similar  temporal  overlays  can  be  constructed  for  other  input-output  specifications  with  sets,  such  as 
Each,  Set-find,  Restrict,  and  Any.  Iterative  temporal  overlays  for  Each  and  Set-find  are  shown  in 
Table  9-T.  Iterative-temporal-each  is  just  like  Temporal-map,  except  rather  than  abstracting  the  streams 
of  inputs  and  outputs  to  an  iterative  application  as  sequences,  they  are  abstracted  as  sets.  Iterative- 
temporal-find  is  just  like  Temporal-earliest,  except  the  steady  state  stream  of  inputs  is  also  abstracted  as  a 
set 


Tabic  9-S.  Temporal  Transitive  Gosure. 

IOspec  ©transitivc-closurc-itcrator  /  .input(iterator)  =>  ,output(set) 
postconditions  .output = transitive-closure(.input,.in) 

TemporalOverlay  iterativc-temporal-transitivc-closure: 

iterative-generation  -» ©transitive-closure-iterator 

correspondences 

tcmporal-iterator(itcrative-gencration)  =  @transitive-closurc-iterator.input 
A  list>set(gencration-stream(itcrative-gencration)) 

=  @,transitivc-closurc-itcrator.output 
A  iterative-gencration.action.in  =  ©transitive-closurc-iterator.in 


1.  More  precisely,  this  abstraction  is  appropriate  when  order  doesn't  matter  and  either  there  are  no  duplicates  or  the  occurrence  of 
duplicates  doesn't  matter. 
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Figure  9*18.  Iterative  Generation  as  Transitive  Gosure. 
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Table  9-T.  Temporal  Each  and  Find 

TemporalOverlay  itcrative-tcmporal-cach :  iterative-application  -*  each 
correspondences 

iterativc-application.action.op = each.op 
A  list>set(application-in-strcam(iterative-application))=each.old 
A  list>sct(application-out-stream(itcrativc-application)) = each.new 

TemporalOverlay  itcrative-temporal-find :  iterative-search  -♦  set-find 
correspondences 

iterative-search.exit.if.criterion = set-find.criterion 
A  list>set(stcady-state-stream(itcrative-search)) = set-fmd.universe 
A  iterative-search.exit.cnd.output  =  set-find.output 
A  iterative-search.exiuend.out = set-find.out 


Table  9-U.  Temporal  Restrict 

TemporalOverlay  filtering-in-stream :  iterative-filtering  -*  list 
correspondences  itcrativc-filtcring.filter.if.input = listhead 
A  filtcring-in-strcam(iterative-filtering.tail)= lisLtail 

TemporalOverlay  filtering-succeed-strcam :  iterative-filtering  -*■  list 
definition  S- filtcring-succeed-strcam(F)  s 

[  [  T.filtcr.if. failed  3  S  =  filtering-succeed-stream(F.tail) ) 

A  [  F.filter.if-succeed^  J. 

3  [  A'.head^  T.filter.if.input  A  S.tail  =  filtering-succeed-stream(F.tail)  ]  J  J 

TemporalOverlay  iterative-tcmporal-restrict :  iterative-filtering  -*  restrict 
correspondences 

iterative-filtcring.filter.if.criterion  =  restrictxriterion 
A  list>sct(filtering-in-stream(iterative-filtering))=restrict.old 
A  list>sct(filtering-succecd-stream(iterative-filtering))=rcstrict.new 


Table  9-VJ  shows  the  temporal  implementation  of  Restrict  as  a  filtering  loop.  The  overlays 
Filtcring-in-strcam  and  Filtcring-succccd-strcam  (see  Fig.  9-19)  describe  how  to  temporally  abstract  the 
stream  of  input  values  to  the  test  of  a  filtering  loop  and  the  stream  of  values  seen  in  an  environment 
where  the  test  has  succeeded  (i.c.  in  the  Then  role).  The  definition  of  Filtcring-in-strcam  has  the  same 
recursive  form  as  the  temporal  overlays  for  iterative  generation  and  application  introduced  earlier. 
F'iltcring-succecd-strcam  is  more  complicated.  The  basic  idea  of  this  definition  is  to  skip  the  inputs  which 
do  not  satisfy  the  test  predicate.  ITiis  is  done  by  defining  the  stream  abstraction  when  the  test  fails  to  be 
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Figurc  9-19.  Stream  Attractions  of  Iterative  Filtering. 
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the  same  as  the  stream  abstraction  of  the  next  time  around  the  loop  (i.e.  the  tail  of  the  recursive  plan).1 

The  last  overlay  in  Table  9-U  is  Iterativc-temporal-restrict,  also  shown  in  Fig.  9-20.  This  overlay 
has  a  similar  structure  to  all  the  other  temporal  set  overlays  in  this  section.  The  Old  set  input  to  Restrict 
corresponds  to  the  input  values  of  the  filter  test.  The  New  set  output  corresponds  to  the  input  values 
selected  by  the  succeed  case.  Hie  Criterion  of  Restrict  is  the  same  as  the  Criterion  of  the  filter  test 

The  last  temporal  overlay  in  this  section  is  an  example  of  how  to  temporally  abstract  a  loop  with 
two  exits  (a  specialization  of  Cascade-itcrativc-termination).  In  particular,  wc  consider  here  the  plan 
Tcrminatcd-itcrative-search,  defined  in  Table  9-V  and  shown  on  the  left  of  Fig.  9-21,  in  which  the  second 
exit  test  (If-two)  is  performing  a  search.  This  means  that  this  test  is  an  instance  of  @  Predicate,  and  when 
the  test  succeeds,  the  input  tested  becomes  the  output  object  of  the  corresponding  join  (F.nd-two),  just  as 
in  Iterative-search.  When  the  first  test  (If-one)  succeeds,  it  means  that  the  search  has  failed.  The 
following  is  an  example  of  how  this  kind  of  loop  might  be  coded  for  searching  a  finite  Lisp  list 


Tabic  9-V.  Temporal  Any. 

Temporal  Plan  tenninated-iterative-search 
specialization  cascade-itcrativc-termination 

roles  .if-one(test)  .if-two(@prcdicate)  .end-oneQoin)  .end-two(join-output) 
.tail(tcrminated-iterative-search) 
constraints  ,if-two.input= .end-two.succccd-input 
a  ,tail.end-two.output= .end-two.fail-input 

TemporalOverlay  iterative-tcmporal-any :  tenninated-iterative-search  -*■  any 
correspondences 

list>set(termination-in-stream(cascadc>itcrativc-termination(terminatcd-iterative-search)) 

=  any.universe 

A  terminated-iterative-search.if-two.criterion  =  any  .criterion 
A  tcrminated-iterative-scarch.cnd-two.output= any.output 
A  tcrminated-itcrativc-scarch.cnd-onc.out=any.fail 
A  terminated-iterativc-scarch.end-two.out= any. succeed 


i.  This  is  a  somewhat  awkward  construction,  but  1  could  not  think  of  a  better  way  of  formally  defining  the  idea  of  leaving  out  parts 
of  the  input  stream,  this  way  of  modelling  filtering  is  also  motivated  by  considering  the  general  ease  of  tree  recursion,  where  the 
structure  of  the  selected  inputs  has  to  be  like  the  structure  of  the  input  tree  with  chunks  missing  at  various  places  in  the  middle. 


\Mi  VvdicA-  ivt' s.  eqroW 
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(PROG  (L  ENTRY) 

LP  (COMO  ((NULL  L)(GO  FAIL))) 
(SETQ  ENTRY  (CAR  L)) 

(CONO  ((P  ENTRY) 

(GO  SUCCEED))) 

(SETQ  L  (COR  L)) 

(GO  LP) 

SUCCEED  ...ENTRY... 

FAIL  !."!) 


However  .a  more  typical  way  of  coding  Tcrminated-itcrative-scarch  in  Lisp  is  illustrated  by  the 
following  code  from  the  symbol  table  example. 


(DEFINE  LOOKUP 
( LAH8DA  (...) 

(PROG  (8KT  ENTRY) 

LP  (COND  ((NULL  BKT)(RETURN  NIL))) 

(SETQ  ENTRY  (CAR  BKT) ) 

(COND  ((...ENTRY...)  (RETURN  ENTRY)) 
(StTQ  BKT  (CDR  BKT)) 

(GO  LP))))) 


Here  rather  than  maintaining  two  control  flow  paths  to  represent  the  succeed  and  fail  cases,  the 
result  of  the  search  is  encoded  in  a  flag  (entry)1  which  is  returned  as  the  output  of  the  loop.  1  believe  this 
should  be  understood  as  an  artifact  of  the  restriction  in  Lisp  that  a  procedure  can  have  only  one  return 
point.  The  original  two  control  flow  paths  are  typically  recovered  when  the  procedure  is  invoked,  as  in 
the  following  code. 


(SETQ  FOUND  (LOOKUP  ...)) 
(COND  (FOUND  ...FOUND...) 
(T  ...)) 


If  the  stream  of  inputs  to  the  second  test  of  Tcrminatcd-iterative-search  is  abstracted  as  a  set,  this 
plan  can  be  viewed  as  the  implementation  of  the  Any  specification,  as  shown  in  Table  9-V  and  Fig.  9-2L 
Specifically,  the  Universe  of  Any  is  the  (finite)  set  of  inputs  to  If-two  under  the  assumption  that  that  exit 
is  never  taken.  The  criterion  of  If-two  corresponds  to  the  criterion  of  Any;  the  output  of  End-two 
corresponds  to  the  output  of  Any;  and  the  output  situations  of  End-one  and  End-two  correspond  to  the 
Fail  and  Succeed  situations  of  Any,  respectively. 


Accumulation 


This  section  discusses  various  ways  to  abstract  iterative  accumulation  programs  such  as  the 
following. 


1.  This  idea  of  a  flag  is  formalized  in  the  appendix. 
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(PROG  (ACCOM  ...) 

(SETQ  ACCOM  ...) 

LP  (CONO  ((...){ RETURN  ACCUN))) 

(SETQ  ACCUM  (CONS  ...  ACCUN)) 

(GO  LP)) 

To  begin,  the  following  is  the  temporal  overlay  for  viewing  the  Input’s  to  the  Add  steps  of  an 
accumulation  loop  as  a  list. 

TemporalOverlay accumulation-stream:  iterative-accumulation  -*■  list+nil 
definition  S = accumulation -strcam(/l)  = 

[  [  /f.cxit.if.succeed*  -L  3  S=  nil  ] 

A  [  zl.cxit.if.fail*  A.  3  { i'.hcad  =  zl.add.input  A  S.tail  =  accumulation-in-stream(>4.tail)  ]  ]  ] 

This  definition  breaks  down  into  two  cases:  if  the  recursion  terminates  on  the  current  level,  then 
the  temporal  abstraction  of  the  inputs  is  Nil;  otherwise,  the  head  of  the  list  is  the  current  Add.Input  and 
the  tail  is  defined  recursively. 

The  special  case  of  iterative  accumulation  in  which  the  Add  roles  are  filled  by  instances  of  Push, 
and  the  Init  is  an  instance  of  Nil,  is  called  Itcrative-list-accumulation,  as  shown  in  Table  9-W.  Fig.  9-22 
show  how  Itcrative-list-accumulation  can  be  viewed  as  the  operation  of  making  the  stream  of  Input’s  to 
Add  in  the  temporal  viewpoint  available  (in  reverse  order)  as  the  output  of  an  accumulation  loop.1 


Table  9-W.  List  Accumulation. 

TeinporalPlan  itcrative-list-accumulation  specialization  iterative-accumulation 
roles  .exit(cond)  .init(objcct)  .add(push)  .tail(iterative-list-accumulation) 
constraints  -init = nil 

TemporalOverlay  itcrativc-Iist-accumulation>@rcvcrse :  iterative-list-accumulation  -»  ©reverse 
correspondences 

list>scqucnce(accumulation-stream(itcrativc-list-accumu!ation))=@reverse.input 
A  list>sequcncc(iterative-list-accumulation.cxiLcnd.output)  =  ©reversc.output 
A  itewtive-list-accumulation.in=@rcverse.in 
A  iterative-list-accumulation.out  =  ©reverse.out 

lOspec  @reversc  /  .op(function)  .input(finite-scquence)  =>  .output(fmite-sequence) 
specialization  ©function 
preconditions  .op  =  reverse 


1 .  Reverse  is  a  standard  relation  on  sequences  defined  in  lhc  appendix. 
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Figure  9*22.  Accumulating  a  Stream  as  a  last. 
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Thus  this  overlay  gives  a  crucial  correspondence  between  the  temporal  viewpoint  taken  inside  a 
loop  and  objects,  such  as  Exit.End.Output,  which  come  out  of  the  loop  and  arc  used  later.  For  example, 
the  following  program  to  reverse  a  Lisp  ’ist1  is  analyzed  as  the  temporal  composition  of  an  instance  of 
Car+cdr+null,  which  generates  the  stream  of  inputs  to  cons  at  the  point  underlined  below,  with  an 
instance  of  Itcrative-list-accumulation,  which  accumulates  the  stream  in  reverse  order  as  the  list  in  m. 

(DEFINE  REVERSE 
(LAMBDA  (L) 

(PROG  (M) 

LP  (COND  ((NULL  L)(RETURN  M))) 

(SETQ  M  (CONS  ( CAR  L 1  M) ) 

(SETQ  L  (COR  L)) 

(GO  LP)))) 

Similarly,  the  special  case  of  iterative  accumulation  in  which  the  Add  roles  are  filled  by  instances  of 
Set-add,  and  the  Init  is  an  empty  set,  can  be  viewed  as  the  operation  of  making  the  stream  of  Input’s  to 
Add  in  the  temporal  available  as  a  set  outside  the  loop.2  This  overlay  is  shown  in  Table  9-X  and 
Fig.  9-23. 

Another  special  case  accumulation  plan  which  is  abstracted  in  terms  of  sets  is  Iterative-aggregation, 
shown  in  Table  9-Y.  In  this  plan  the  Add  roles  are  filled  by  applications  of  an  aggregative  function  (such 
as  Plus,  Times,  or  Union),  and  the  Init  of  the  accumulation  is  the  identity  clement  of  that  function. 
Iterative-aggregation  can  be  viewed  as  a  temporal  implementation  of  Aggregate,  as  defined  by  the  overlay 
Temporal-aggregate  in  Table  9-Y  and  as  shown  in  Fig.  9-24.  The  stream  of  Input’s  to  Add,  viewed  as  a 
set,  corresponds  to  the  input  to  Aggregate.  'ITic  aggregative  function  applied  by  Add  is  the  Binop  of 
Aggregate.  The  output  of  the  end  join  of  the  iterative  plan  corresponds  to  the  output  of  Aggregate. 

A  further  overlay,  not  shown  here,  can  be  defined  to  analyze  accumulation  loops  in  which  the 
function  applied  is  aggregative,  but  the  Init  is  not  the  identity  element;  as  for  example  a  summation  loop 


Table  9-X.  Set  Accumulation. 

TemporalPlan  iterative-set-accumulation  specialization  iterative-accumulation 
roles  .cxit(cond)  .init(sct)  .add(set-add)  .tail(iterative-set-accumulation) 
constraints  cmpty(.init) 

TemporalOvcrlay  itcrative-tcmporal-set-accuiuulation :  iterativc-sct-accumulation  -*  set 
properties  V  A  l  instancc(iicrative-set-accumulation,/4) 

D  itcrativc-tcmporal-sct-accumulation(/!)=  /f.cxiLcnd.output  J 

correspondences 

list>sct(accumulation-strcam(itcrative-sct-accumulation))=set 


1.  In  which  Push  is  implemented  as  CONS. 

2.  Notice  that  at  this  level  of  abstraction,  we  don’t  say  exactly  how  this  set  (and  therefore  Set-add  and  limply)  arc  implemented. 
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Table  9-Y.  Temporal  Aggregate. 

TemporalPlan  iterative-aggregation  specialization  iterative-accumulation 
roles  .exit(cond)  .init(objcct)  .add(@aggrcgative)  .tail(iterative-aggregation) 
constraints  identity(.add.binop,.init) 

lOspec  ©aggregative  /  .binop(aggregative-binfunction)  .old(objcct)  .input(object) 

=>  .new(object) 

extension  old+input+new 

postconditions.  binapply(.binop,.old,. input) = .new 

TemporalOverlay  temporal-aggregate :  iterative-aggregation  -»  aggregate 
correspondences 

list>set(accumulation-stream(iterative-aggregation)) = aggregate.input 
A  iterative-aggregation. add.binop  =  aggregate.binop 
A  iterative-aggregation.exit.end.output = aggregate.output 
A  iterative-aggregation.exiLend.out= aggregate.out 


which  starts  with  an  initial  sum  of  5.  Such  loops  can  be  abstracted  as  an  Aggregate  operation  in  which  the 
input  set  is  obtained  by  adding  the  Init  to  the  Accumulation-stream,  viewed  as  a  set 

Non-Iterative  Temporal  Abstraction 

This  section  discusses  singly  recursive  programs  in  which  there  is  computation  "on  the  way  up”,  Le. 
in  which  the  recursive  invocation  is  not  the  last  step  in  the  program.  The  kind  of  computation  most 
commonly  performed  on  the  way  up  is  accumulation,  such  as  the  following  program  with  Lisp  list 
accumulation  on  the  way  up. 

(DEFINE  C0PYLIST 
(LAMBDA  (L) 

(COND  ((NULL  L)  NIL) 

(T  (CONS  (CAR  L)(COPYLIST  (CDR  L))))))) 

One  way  of  thinking  about  this  programming  technique  is  to  compare  the  program  above  with  the 
reverse  program  of  the  last  section,  which  has  the  same  generation  part,  but  in  which  the  list 
accumulation  is  done  iteratively  ("on  the  way  down").  This  comparison  is  made  easier  by  re-coding 
reverse  tail  recursively  as  shown  below.1 


1.  The  two  different  lisp  codings  have  the  same  plan. 
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(DEFINE  REVERSE 
(LAMBOA  (L) 

(REVERSE  1  L  NIL)))) 

(DEFINE  REVERSE1 
(LAMBDA  (L  M) 

(CONO  ((NULL  L)  M) 

(T  ( REVERSE  1  (COR  L)(C0NS  (CAR  L)  M)))))) 

In  effect,  the  non-iterative  program  above  is  using  the  stack  provided  by  the  Lisp  language 
implementation  to  reverse  the  order  of  objects  flowing  from  the  list  generation  to  the  list  accumulation,  in 
order  to  cancel  out  the  order  reversal  introduced  by  the  accumulation.  The  rest  of  this  section  will  show 
how  to  formalize  this  way  of  understanding  accumulation  on  the  way  up  in  terms  of  the  corresponding 
iterative  accumulation  with  an  intervening  order  reversal.1  Similar  plans  and  overlays  for  other  basic 
recursive  computations  on  the  way  up  (generation,  application,  etc.)  can  be  constructed,  but  are  much  less 
common  in  typical  programming  use.2 

In  terms  of  the  plan  calculus,  the  difference  between  iterative  and  non-iterative  singly  recursive 
(linear)  temporal  plans  is  whether  there  is  anything  but  instances  of  Join  (or  Join-output)  after  the 
recursive  invocation  (Tail).  Instances  of  Join  and  Join-output  on  the  way  up  are  required  in  iterative 
plans  to  specify  via  control  flow  that  the  entire  computation  ends  when  any  of  its  tails  end,  and  to  return 
any  final  values.  In  the  plan  for  the  copylist  program  above,  which  is  non-iterative,  an  instance  of 
©Function  (the  Add  role  of  the  accumulation)  comes  after  the  tail.  The  plans  for  iterative  and  non¬ 
iterative  linear  accumulation  can  be  compared  diagrammatically  on  the  right  and  left  sides,  respectively, 
of  Fig.  9-25. 

Table  9-Z  defines  these  two  plans  as  specializations  of  a  more  general  plan  called  Linear- 
accumulation.3  The  constraints  on  this  plan  require  only  that  the  accumulation  function  applied 
( Add.Binop)  be  the  same  each  time,  and  that  the  Add  step  occur  once  at  each  level  in  the  recursion  except 
when  the  exit  test  succeeds.  Also,  in  both  the  iterative  and  non-iterative  versions,  the  Init  object  is 
returned  when  the  recursion  terminates  on  the  very  first  exit  test. 

Iterative-accumulation  is  obtained  as  a  specialization  of  Linear-accumulation  by  adding  the 
constraint  that  the  Add  step  precedes  the  Tail,  so  that  accumulation  is  done  on  the  way  down.  There  is 
then  data  flow  from  Add.New  to  Tail.Add.OId.  Also,  in  this  form  of  accumulation,  the  Init  at  each  level 
is  the  same  as  the  output  of  the  preceding  Add.  This  can  be  seen  in  the  reverse  program  above,  in  which 
the  value  returned  is  m,  which  is  set  to  (cons  (car  l  )  mj  by  the  preceding  repetition. 


].  The  cancellation  between  the  reversal  of  the  order  of  inputs  on  the  way  up  and  the  reversal  introduced  by  the  iterative 
accumulation  is  a  particular  property  of  List-accumulation.  The  reversal  on  the  way  up  is  a  general  property  of  non-iterative 
temporal  abstraction. 

2.  In  fact  even  the  other  common  accumulations,  other  than  list  accumulation,  are  seldom  done  on  the  way  up,  since  the  order 
reversal  is  immaterial  when  the  streams  arc  viewed  as  sets. 

3.  This  table  contains  an  equivalent  resiatcmcnt  of  the  Iterative-accumulation  plan  introduced  earlier,  where  only  loops  were  being 
considered. 
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Tabic  9-Z.  Iterative  and  Non-iterative  Accumulation. 

Temporal  Plan  linear-accumulation  extension  iterative-termination 
roles  .exit(cond)  .init(object)  .add(old+input+new)  .tail(lincar-accumulation) 
constraints  .init  =  .exiLcnd.succeed-input 

A  (.exit-if.fail^  _L  «-*  .add.in*  ±)  A  (.add.in*  J_  *-»  .tail.exiuif.in^X) 

Temporal  Plan  iterative-accumulation 
specialization  linear-accumulation  iterative-termination-output 
roles  .cxit(cond)  .init(objcct)  .add(old+input+new)  .tail(  iterative-accumulation) 
constraints,  add.old  =  .init  A  .add.ncw  =  .tail.add.old  A  precedcs(.add.out,.tail.add.in) 

TemporalPlan  reverse-accumulation  specialization  linear-accumulation 
roles  .cxitfcond)  .init(object)  .add(old+input+new)  .tail(reverse-accumulation) 
constraints  instancc(join-output,.exiLend) 

A  .tail.exitend.output=.add.old 
A  ,add.new  =  .exit.end.fail-input 
A  .init=.init.tail  A  precedes(.tail.add.out,.add.in) 


Reverse-accumulation,  the  plan  for  the  non-iterative  case,  is  obtained  as  a  specialization  of  Linear- 
accumulation  by  constraining  the  Add  step  to  follow  the  Tail,  so  that  accumulation  is  done  of  the  way  up, 
and  adding  data  flow  to  the  Add.Old  to  Tail.Add.New,  via  the  join  of  the  Tail.  Also,  in  this  form  of 
accumulation,  the  Init  is  the  same  at  each  level,  as  can  be  seen  in  the  COpylist  program  above,  in  which 
nil  is  returned  from  whichever  recursive  invocation  finally  causes  the  cond  to  succeed. 

Given  this  framework,  the  Accumulation-stream  overlay  can  be  generalized  to  apply  to  instances  of 
either  Iterative-accumulation  or  Reverse-accumulation. 

Finally,  as  shown  in  Table  9-AA  and  Fig.  9-25,  the  implicit  order  reversal  of  accumulation  cn  the 
way  up  (as  compared  to  on  the  way  down)  can  now  be  modelled  as  an  overlay,  Revcrsoiterative- 
accumulation,  which  establishes  a  correspondence  between  these  two  versions  in  which  the  type  of  the 
Add  operations,  the  Ink’s,  and  final  outputs  correspond,  but  the  accumulation  input  streams  are  reversed. 


Table  9-AA.  Temporal  Reverse. 

TemporalOverlay  rcversoitcrativc-accumulation :  reverse-accumulation  -*  iterative-accumulation 
correspondences 

list>scquencc(rcvcrsc(accumulation-strcam(  reverse-accumulation))) 

=  list>scqucncc(accumulation-strcam(itcrativc-accumulation)) 

A  reverse-accumulation.init  =  itcrativc-accumulation.init 
A  reverse- accumulation.add  =  itcrative-accumu!ation.add 
A  rcversc-accumulation.cxit.cnd.output  =  iterativc-accumulation.cxit.cnd.output 
A  reverse- accumulation.cxit.cnd.out  =  itcrative-accumulation.cxit.cnd.out 
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Similar  overlays  can  be  constructed  between  the  iterative  and  non-iterative  versions  of  other  recursive 
plans,  such  as  generation,  application,  etc. 

9.4  Recursive  Structures 

This  section  sketches  how  the  epistemology  of  singly  recursive  data  structures  (lists,  etc.)  and 
temporal  plans  (loops,  etc.)  of  the  last  two  sections  can  be  generalized  to  double  and  multiple  recursion. 
Only  a  small  amount  of  formal  definition  will  be  presented  in  this  section,  however,  since  the  plans  and 
overlays  for  double  and  multiple  recursive  structures  tend  to  be  longer  and  more  detailed  than  those  for 
linear  structures,  without  introducing  any  fundamentally  new  ideas. 

Table  9- A  B  shows  the  basic  idea  of  double  recursion.  The  data  plan  Double-recursion  has  two 
roles.  Left  and  Right,  which  are  either  themselves  instances  of  Double-recursion,  or  of  type  Atom,  which 
is  a  primitive  type  used  to  terminate  multiple  recursions.  Finite  double  recursion  is  defined  analogously 
to  finite  single  recursion.  Recursion  with  a  varying  number  of  recursive  instances  at  each  level  can  be 
defined  in  terms  of  a  single  role  which  is  constrained  to  be  a  set,  each  of  which  is  either  a  recursive 
instance  or  an  atom. 

The  doubly  recursive  data  structure  analogous  to  List  is  Binlist  (binary  list),  a  data  structure  with 
one  head  and  two  "tails”.  Left  and  Right.  The  binary  data  structure  corresponding  to  Thread  in  the 
linear  case  is  Bintree.  and  in  the  general  case.  Tree.  In  Lisp  programming,  binary  trees  are  a  more 
common  data  structure  than  binary  lists,  since  a  binary  tree  may  be  easily  constructed  out  of  dotted  pairs, 
as  described  by  Car-cdr-gencrator  (see  Table  9-AC).  A  double  recursion  may  be  viewed  as  a  binary  tree 
in  which  the  left  and  right  recursive  instances  correspond  to  subtrees  whose  roots  are  successors  of  the 
root  of  the  binary  tree,  as  specified  by  the  following  overlay. 


Table  9-AB.  Double  Recursion. 

DataPlan  double-recursion 

roles  .left(double-rccursion+atom)  .right(double-rccursion+atom) 
Type  atom 

Type  double-recursion+atom  unionlype  double-recursion  atom 

DataPlan  binlist  extension  double-recursion 
roles  .head(objcct)  .lcfl(binlist+atom)  .rightfbinlist+atom) 

Type  binlist+atoni  unionlype  binlist  atom 


t 
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DataOverlay  double-recursion>bintrce :  double-rccursion+atom  -*  bintree 
definition  7'=doublc-rccursion>bintrcc(/J,s)  = 

[[  instance(atom,doublc-rccursion+atom( /?,$))  *■*  terminal(7’,root(7))] 

A  |  instance(double-recursion,double-recursion+atom(#,s))  D 
root(7’,jr)  A 

[root(doublc-rccursion>bintrec(double-rccursion+atom(/?,s).left,s),ly) 
v  root(double-rccursion>bintrcc(doublc-recursion+atom(/t,s).right,s))] 
o  succcssor(7,xj»)  ]  ]  J 

The  basic  plans  for  unbounded  iterative  computation  introduced  earlier  in  this  chapter,  generation, 
application,  termination,  filtering,  and  accumulation,  can  also  be  generalized  to  double  and  multiple 
recursion.  For  example.  Table  9- AC  and  Fig.  9-26  show  the  plan  for  doubly  recursive  generation,  such  as 
in  the  following  code. 

(DEFINE  GENERATE 
(LAMBDA  (S) 

...(GENERATE  (CAR  S) > _ 

_ (GENERATE  (COR  S) ) _ )) 

The  overlay  Temporal-binary-generator  is  analogous  to  Temporal-iterator  for  loops.  It  specifies 
how  Binary-generation  can  be  viewed  as  the  temporal  implementation  of  the  generator  for  a  binary  tree. 
For  example,  this  is  the  overlay  which  relates  the  code  above  to  the  Lisp  binary  tree  generator  Car-cdr- 
generator. 


Table  9-AC.  Binary  Generation. 

TemporalPlan  binary-generation  extension  double-recursion 
roles  .currcnt(objcct)  ,action-lcft(<P’function)  .action-right(@function) 
,left(binary-generation)  .right(binary-gcneration) 
constraints  .current = .action-leftinput  A  .current  =  .action-righLinput 

A  .lcfuction-lefLop  =  .action-left.op  A  .right.action-right.op=action-right.op 
A  .action-lcft.output=  JcfLcurrent 
A  .action-right.output=.right.currcnt 

TemparalOvcrlay  teniporal-binary-gcnerator :  binary-generation  -*  binary-generator 
correspondences  binary-gcneration.currcnt  =  binary-generator.seed 
A  binary-gcncration.action-lcft.op  =  binary-gencrator.left 
A  binary-gcneration.action-right.op  =  binary-gencrator.right 

DataPlan  binary-generator 
roles  .sccd(object)  .lcft( function)  .right( function) 

DataPlan  car-cdr-gcncrator  specialization  binary-generator 
roles  .sccd(dottcd-pair)  .lcft(function)  ,right(  ftinction) 
constraints  .left = car  A  .right = edr 
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Notice  that  there  arc  no  constraints  in  the  Binary-generation  plan  between  the  order  of  execution  of 
the  left  and  right  recursive  invocations.  Standard  traversal  orders  for  binary  trees  (such  as  pre-  and  post- 
order)  are  represented  as  specializations  of  Binary-generation.  In  the  temporal  view,  these  traversal 
orders  can  be  viewed  as  overlays  w  hich  "flatten"  a  tree  into  a  linear  structure  in  different  ways. 

Temporal  abstraction  of  multiple  recursive  plans  gives  rise  to  tree  structured  streams  and  reverse 
streams.  Operations  on  these  temporal  abstractions  are  the  generalizations  of  the  corresponding 
operations  on  temporal  sequences,  such  as  Iterate,  Map,  Truncate,  and  so  on.  A  particularly  important 
doubly  recursive  temporal  plan  is  binary  tree  accumulation,  as  in  the  following  code. 

(DEFINE  COPYTREE 
(LAMBDA  (S) 

(CONO  ((ATOM  S)  S) 

(T  (CONS  (COPYTREE  (CAR  S) ) 

(COPYTREE  (CDR  S))))))) 

The  plan  for  this  program  is  the  temporal  composition  of  binary  generation  with  binary  truncation 
(on  atom),  and  binary  accumulation  in  which  the  accumulation  function  constructs  an  instance  Double- 
recursion  from  a  given  left  and  right.  For  binary  trees  in  Lisp,  this  construction  operation  is  implemented 
by  cons. 
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APPENDIX 

PLAN  LIBRARY  REFERENCE 


1.  SETS 

Type  set 

Function  size:  set  -*  cardinal 
Function  set-type :  set  -*  type 

properties  VSP [  set-type(S)=  P  D  {  Vor  [  (jr  €  S)  O  instance! /\jc) )  ]  ] 
Type  finitc-sct  subtype  set 

definition  instance(fmite-set,5)  =  [  instance(set,S)  A  finite(size(S))  ] 


1.1  Relations  on  Sets 

Predicate  empty:  set  -*  boolean 
properties  VS  [  empty(S)  **  size(S)=0  ] 
definition  cmpty(S)  =  Vx(x{  S) 

Predicate  universal :  set  -*  boolean 
definition  universal(S)  =  Vjc(x  €  S) 

Binrel  disjoint :  set  X  set  -*  boolean 
definition  disjoint(S,7')  =  Vx  ->[  (x  €  S)  A  (x  €  T)  ] 

Binrel  subset:  set  X  set  -*•  boolean 
properties  instancc(partial-order, subset) 
definition  subset (S,T)=  Vx  [  (x  €  S)  D  (x  €  7)] 


1.2  Input-Output  and  Test  Specifications  with  Sets 

lOspcc  set-find  /  .univcrsc(sct)  .critcrion(prcdicatc)  =*>  ,output(object) 
preconditions  sct-typc(.univcrsc)= domain-type(  .criterion) 

A  3or  [  (jr  c  .universe)  A  apply! .criterion,.*) = true  ] 
postcondition:  (.output  €  .universe)  A  apply(.critcrion,.output)=true 
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IOspec  each  /  .old(set)  .op(function)  =>  .new(set) 
preconditions  set-typc(.old)=domain-type(.op)  A  subset(.old,domain(.op)) 
postconditions  set-typc(  .new)  =  rangc-type(.op) 

A  Vy  ( O'  €  .new)  «-*  3x  ( (x  €  .old)  A  apply(.op,x)=y')  J 

IOspec  restrict  /  .old(set)  .critcrion(predicate)  =>  .ncw(set) 
preconditions  set-ty  pc(.old) = domain-type(.criterion) 
postconditions  set-typc(.new) = set-ty  pe(.old) 

A  Vx{  (x  €  .new)  [tx  e  .old)  A  apply(.criterion,x)=trueJ) 

IOspec  set-add  /  .old(sct)  .input(object)  =>  .new(set) 
specialization  o!d+ input+new-set 
preconditions  instance(set-type(.old),.input) 
postconditions  set-type(.new)  =  sct-typc(.old)  A  (.input  €  .new) 
a  Vx  [  x*  .input  3  [  (x  €  .old)  **  (x  €  .new)  ]  J 

IOspec  set-remove  /  .old(sct)  .input(object)  <=>  .new(set) 
specialization  old+input+new-set 
preconditions  instancc(set-type(.old),. input) 
postconditions  set-type(.new) = set-typc(.old)  A  (.input  4  .new) 

A  Vx  [  x*  .input  3 1  (x  €  .old)  «■*  (x  €  .new)  ]  ]  t 

Test  any  /  xinivcrsc(finitc-sct)  .critcrion(predicatc)  =>  .output( object)  succeed 
condition  3x  [  (x  e  .universe)  a  apply(.criterion,x) = true ) 
postconditions  (.output  €  .universe)  A  apply(.criterion, .output) = true 

Test  member?  /  .universe(set)  .input(object) 
condition  .input  €  .universe 


1.3  Aggregating  a  Set 

IOspec  aggregate  /  .input(finitc-sct)  .binop(aggrcgativc-binfunction)  =>  .output(object) 
preconditions  ->cmpty(.input)  a  subsct(.input,argtype-onc(.binop).instances) 
postconditions  2QT[  instance(irrcdundant-sequence,0 
A  instancc(irrcdundant-sequence,7) 

A  .input =scquence>set(Q,j) 

A  length!  T ) = Icngth(Q) 

A  first(7)  =  first(Q) 

A  Vi I-indcx(T,/)  A  r*l  3 

apply(7,/) = binapply(.binop,apply«?,r).apply(  7,oneminus(/)))  J 
A  .output=Iast(7)J 


i 


i 

i 
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IOspec  sum  /  .input(finitc-set)  .binop(aggregative-binfunction)  =>  .output(object) 
specialization  aggregate 
preconditions  .binop  =  plus 

IOspec  product  /  .input(finite-set)  .binop(aggregative-binfunction)  =>  .output(object) 
specialization  aggregate 
preconditions  .binop  =  times 

IOspec  aggregate-union  /  .input(finite-sct)  .binop(aggregativc-binfunction) 

=>  .output(object) 

specialization  aggregate 
preconditions  .binop = union 

IOspec  aggregate-intersection  /  .input(finite-set)  .binop(aggrcgative-binfunction) 

=>  .output(object) 

specialization  aggregate 
preconditions  .binop = intersection 

IOspec  max  /  .input(finitc-set)  .binop(aggrcgative-binfunction)  =>  ,output(object) 
specialization  aggregate 
preconditions  .binop = greater 

IOspec  min  /  ,input(finitc-sct)  .binop(aggrcgativc-binfunction)  =*■  .output(object) 
specialization  aggregate 
preconditions  .binop  =  lesser 


1.4  Linear  Implementations  of  Sets 

DataOverlay  list>sct :  list+nil  -*  set 
properties  VI.s[  list+nil(/.,s)  =  nil  *-*  cmpty(list>set(Z,,s))  J 

definition  T=  list>sct(/.,s)  =  Vx  [ (jc  €  T)  [  jt = Iist(Z.,r).head  v  (*  €  list>sct(list(Z^s).tail,s))  1  ] 

DataOverlay  sequence>sct :  sequence  -*•  set 
properties  V<?s[  list>sct(sequcncc>list(£),s))=scquence>set(@,j) 

A  [  instance(irrcdundant-scqucncc,scqucnce((?,s))D 

length(scquencc((?,j))= si/e(scqucnce>scl(£?,s))  ]  ] 
definition  r=scqucncc>sct(<2,j)  =  Vjc [ (jt  €  T)++  3/ apply(scqucncc((?,s),i)=x] 

DataOverlay  lahelled-thrcad>sct:  labelled-thread  -» set 
properties  V/.slist>sct(/.,s)=labclled-thrcad>sct(list>labcllcd-thrcad(L,s),s) 
definition  /'=  labelled-thread >sct(7',r)  = 

V*  [( a  c  !■)*-*  3 v  |  riodc(labelled-thrcad( T,s).basc,y)  A  apply(labcllcd-thrcad( 7',s).labcl%y)  =  a  )  ] 


1.5  Implementations  of  Set  Add1 


Temporal  Plan  intcrnal-lubdlcd-tliread-add 
roles  .old(labelled-thrcad)  .add(intcrnal-thrcad-add)  .update(ncwarg) 

.ncw(labcllcd-thrcad) 

constraints  .old.spine  =  .add.old  A  .olddabd  =  ,update.old 
A  .add.input=.update.arg 
A  .add.new  =  .ncw.spine  A  ,updatc.new  =  .new.label 

TemporalOvcrlay  intcrnal-thrcad>set-add :  intcrnal-labellcd-thread-add  -»  set-add 
properties  V/*[  instance(internal-labellcd-thrcad'add,/>)  D 

[  instancc(#internal-thread-add,/>.add)  *-*  instancc(#sct-add,intcrnal-lhrcad>set-add(/)))  ]  ] 
correspondences 

labellcd-thread>sct(intcrnal-labcl!ed-thread-add.old)=set-add.old 
A  intcmaHabcllcd-thrcad-add.update.input = set-add.input 
A  labelled-thrcad>sct(intcrnal-!abcllcd-thrcad-add.ncw)=set-add.new 
A  intemal-labcllcd-thread.add.in  =  set-add.in 
A  internal-labclIed-thrcad.updatc.out=sct-add.out 

TemporalOverlay  push>sct-add :  push  -*•  set-add 
properties  V/*  [  instancc(push,/>)  A  instancc(irrcdundant-list,/>.output) 

O  instancc(sct-add-onc,push>sct-add(/>))  ] 
correspondences  Hsmctfpush.old) = sct-add.old 
A  push.input  =  sct-add.input 
A  list>set(push.ncw)=set-add.ncw 
A  push.in=sct-add.in 
A  push.out=set-add.out 


1.6  Set  Removal  for  Irredundant  Lists 

TemporalOverlay  @ tail+intcmabrestrict:  ©tail+intcmal  -*  rcstrict-one 
correspondences 

Iist>sct(@tail+intcrnal.action.input)  =  rcstrict-onc.old 
A  complcment(@tail+imcmal.updatc.if.criterion)=rcstrict-one.critcrion 
A  list>sct(C“tail+intcrnal.updatc.cnd.output)=rcstrict-one.new 
A  @tail+internal.action.in  =  rcstrict-one.in 
A  @tail+intcrnal.updatc.end.out= rcstrict-one.out 
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lOspec  restrict-one  /  .old(set)  .criterion! predicate)  =>  .new(set) 
specialization  restrict 

preconditions  3x  [  (jr  €  .old)  A  apply!  .criterion, x)  =  false  J 
A  Vxy  [  (x  €  .old)  A  0'  €  .old) 

A  app!y( .criterion, x)= false  A  apply(.criterion,y)=  false  D  x=y] 

Temporal  Plan  @tail+internal 
roles  .action!^  head)  .updatc(cond) 

.interna!(intcrnal-labclled-thread-find+reniove) 
constraints  instance!  (g  predicate, .update.if) 

A  instance!^  tail,.updatc.then) 

A  instance(join-output,.updatc.end) 

A  instancc(irredundant-list,.action.input) 

A  .action.output=.update.if.input  A  cflow(.action.out,.updatc.if.in) 

A  .action.input = .updatc.then.input 
A  .updatc.thcn.output= .updatc.end.succeed-input 
A  update.else.in  =  .internal.find.in  A  update.else.out=.intemal.remove.out 
A  list>labcHcd-thrcad(  .action.input) = .intcmal.o)d 
A  .updatc.if.criterion = .intcrnal.composite.criterion 
A  list>labelled-thread(.internal.new)= .updatc.end.fail-input 

TemporalPlan  internal-labclled-thrcad-find+remove  extension  intcmal-thrcad-find+remove 
roles  .old(labcllcd-thrcad)  .ncw(labcllcd-thrcad)  .composite!  function+prcdicate) 
.find(intcrnal-thrcad-find)  .remove(internal-thread-remove) 
constraints  .old.spinc  =  .fmd.uni  verse  A  .new.spine=.rcmove.new 
A  .old.labcl  =  .  new  .label  A  .old.label  =  ,composite.op 
A  function+prcdicaic>prcdicatc(.compositc)  =  .fmd.criterion 

TemporalPlan  intcrnul-tlircadTmd+rcmove 
ro/ej.find(intcrnal-thrcad-find)  .removc(internal-thread-rcmove) 
constraints . fmd.uni  verse =. remove. old  A  ,find.output=.remove.input 


1.7  Discrimination 

Type  discrimination  subtype  function 
definition  instanccfdiscrimination,/7)  =  [instance! function, F) 

A  Vx  [  instancc(domain-typc(/’),x)  D  (x  £  domain!/7))  J 
A  V6s[(i€  range!/'))  D  sct-typc(set(6,s))= domain-type!/7) ]  ] 

DataOverlay  discrimination>set :  discrimination  -*  set 
definition  Q  =  discrimination>sct(  i\s)  =  [  domain-typc(function(/',j))= set-type! 0 
A  Vx  j (x  €  0  «-*  (x  e  sct( apply! function! /  -,j),x),s)) )  ] 


i 
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1.8  Testing  Membership  in  a  Discrimination1 

TemporalOverlay  discriminatc+mcmbcr?>mcmbcr?:  discriminate+member?  -*  member? 
correspondences 

discrimination>sct(discrimiaate+mcmbcr?.discriminatc.op)=mcmbcr?.universe 
A  discriminate+membcr?.discriminate.input=mcmber?.input 
A  discriminate+mcmbcr?.if.in  =  member?.in 
A  discriminate+membcr?.if.succeed =membcr?.succeed 
A  discriminate+mcmber?.if.fail  =  mcmber?.fail 

TemporatPlan  discriminate+member? 
roles  .discriminate!  (a’function)  .ifl(mcmbcr?) 
constraints  instance(discrimination,.discriminate.op) 

A  .discriminate.output  =  .if.univcrse  A  .discriminate.input=.if.input 
A  cflow(.discriminate.out,.if.in) 


1.9  Updating  a  Discrimination 

7>w/;0w/Over/tfj'discriminate+action+updatc>action: 

discriminate+action+updatc  -»  old+input+new-set 
properties  V  DA  [  /I=discriminatc+action+updatc>action(Z))  D 
[  instance! sct-add,D.action)  <-»  instance(set-add,/I) ) 

A  [  instance!  sct-add-one.D.action)  «-»  instancc(set-add-one,/4)  ] 

A  [  instancc(sct-remove,/?.action)  «-*  instance(sct-remove,/4)  J 
A  [  instance!#  ncwvalue,£>.updatc)  «-*  instance(#old+input+ncw,/I)]] 
correspondences 

discrimination>set(discriminate+action+update.discriminate.op) 

= old+input+ncw-sctoM 

A  discriminate+action+update.discriminate.input=old+input+ncw-set.input 
A  discriminate+action+update.action.input=old+input+new-sct.input 
A  discrimination  >sct(discriminatc+action+update.update.new) 

=  old+input+new-sct.new 

A  discrimrnatc+action+updatc.discriminate.in=old+input+new-set.in 
A  discriminatc+action+update.update.out= old+input+new-setout 


1.  See  Fig.A-2. 
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Figure  A-2,  Testing  Membership  in  a  Discrimination. 


/ 
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Temporal  Plan  discriminatc+action+updatc  extension  action+update 
roles  .discriminate ^function)  .action(old+input+ncw-sct)  .updatc(ncwvalue) 
constraints  instancc(discrimination,.discriminate.op) 

A  .discriminate.output=.action.old 
A  .discrim  inatc.output= .update. value 
A  .action.new  =  .update.input 
A  .discriminate.op  =  .update.old 

A  cflow(.discriminate.out,.action.in)  A  cflow(.action.out,.update.in) 

lOspec  old+input+newset  /  .old(sct)  .input(object)  =>  .new(set) 
specialization  old+input+new 


2.  ASSOCIATIVE  RETRIEVAL  AND  DELETION 

Test  retrieve  /  .universc(finite-set)  .kcy( function)  .input(object)  =>  .output(object)  SUCC£ed 
condition  3x  [  (x  €  .universe)  A  apply(.key,x)=  .input  ] 
postconditions  (.output  €  .universe)  A  apply(.key ..output) =. input 

lOspec  expunge  /  .old(finite-sct)  .key(function)  .input(object)  =>  ,new( finite-set) 
extension  old+input+ncw-set 

postconditions  Vx  [  (x  €  .new)  «-*  [  (x  €  .old)  A  apply( .key ,x)*. input  ]  J 

lOspec  expunge-onc  /  .old(finitc-sct)  .kcy(function)  .input(objcct)  =>  .new(finite-set) 
specialization  expunge 

preconditions  3jr  [  (x  €  .old)  A  apply(.key,x)=. input] 

A  V  Jry  [  (x  €  .old)  A  (y  €  .old) 

A  apply(.key,x) = .input  A  applyf.key^’)  =  .input  3x=y] 

lOspec  ^expunge  /  .old(finitc-sct)  .key(function)  .input(object)  =>  .new(finite-set) 
specialization  expunge 
postconditions  .old = .new 


2.1  Implementation  of  Associative  Retrieval 

TemporalQverlay  any>retrieve :  any-compositc  -*  retrieve 
correspondences  any-composite.universe  =  retricve.univcrse 
.  A  any-composite.compositc,op  =  retrieve.kcy 
A  any-compositc.composite.two  =  rctricvc.input 
A  any-composite.if.output= rctricvc.output 
A  any-compositc.if.in  =  rctricve.in 
A  any-compositc.if.succccd  =  rctrieve.succecd 
A  any-compositc.if.fail  =  rctricvc.fail 


t 
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TemporalPlan  any- composite 
roles  .compositc(function+two)  .ifl[any) 
constraints  function+two>prcdicatc(.composite)=.if.criterion 


2.2  Implementation  of  Associative  Deletion 

TemporalOverlay  restrict>expunge:  restrict-composite  -*  expunge 
properties^ RE [  £=restrict>expunge(fl)  D 

[  instance(rcstrict-one.fl.action) «  instancc(cxpunge-onc,/: )  ] 

A  [ instance(#rcstrict,ff.action)  **  instancefjvcxpunge.f)]] 
correspondences  rcstrict-composite.old = expunge.old 

A  restrict-coinposite.composite.op =expunge.key 
A  restrict-composite.composite.two  =  expunge.input 
A  restrict-composite.action.new  =  expunge.new 
A  restrict-composite.action.in = expunge.in 
A  restrict-composite.action.out= expunge.out 

TemporalPlan  restrict-composite 
rules  .compositc(function+two)  .action(  restrict) 

constraints  complemcnt(function+two>predicate{.composite),.action.criterion) 


2.3  Keyed  Discrimination 

DalaPlan  keyed-discrimination  specialization  composed-functions 
properties  V/)s(  instance(keycd-discriniination,0)  D  instance(discrimination.composed>function(0,s))  J 
roles  .onc(  function)  .two{ function) 
co«s/ra//j/jrangc-type(.two,finite-set) 

A  V7s[(T €  rangc(.two))  O  set-iype(sct( T,s))  -  domain-type(.one)  ] 


2.4  Retrieval  from  a  Keyed  Discrimination 

TemporalOverlay  discriminate+retrievorctrieve :  keycd-discriminate+retrieve  -»  retrieve 
correspondences 

discrimination>sct(composcd>function(keycd-discriminatc+rctrieve.composite)) 

=  retricve.universe 

A  keyed-discriminate+rctrievc.if.key = rctricvc.key 
A  kcyed-discriminate+rctricvc.if.input= rctricvc.input 
A  kcycd-discriminate+rctricvc.if.output=  rctricve.output 
A  kcycddiscriminale+rctrievc.discriminatc.in  =  rctrieve.in 
A  keycd-discriminate+rctrievc.if.succced  =  rctricve.succecd 
A  keycd-discriminatc+rctricvc.if.fail  =  rctrieve.fail 
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TemporalPlan  keyed-discriminatc+retrieve 
roles  .compositc(keycd-discrimination)  .discriminatcKtafunction)  .if(  retrieve) 
constraints  .composite.one  =  .if.key  A  .composite.two  =  .discriminate.op 
A  .discrimmate.input=.if.input 
A  .discriminatc.output=.if.univcrse 
A  cflow(.discriminate.out,.if.in) 


2.5  Associative  Deletion  from  a  Keyed  Discrimination 

7>wi/>wu/<9ver/<y'discriininate+expunge+updatc>expunge: 

kcycd-discriminate+cxpunge+updatc  -*  expunge 
properties  VDE\ E=  discriminate+expungc+update>cxpunge(Z>)  D 

l  insiance(expungc-one,Z).action)  ♦+  instance(expunge-one,£')] 

A I  instance( » newvalue,Z).update)  «-» instance(#expunge,£’)]  ] 
correspondences 

discrimination>sct(composed>function(keyed-discriminate+expunge+update.old)) 

=expunge.old 

A  discrimination>set 

(composcd>function(keycd-discriminate+expunge+update.new)) 

=expunge.new 

A  kcycd-discriminate+expunge+updatc.action.inpul=expunge.input 
A  kcycd-discriminate+expunge+update.action.kcy  -expunge-key 
A  keycd-discriminate+expunge+update.discriminatc.in = expungc.in 
A  keycd-discriminate+expunge+update.update.out= expunge.out 

TemporalPlan  kcyed-discriminate+expungc+update 
extension  discriminatc+action+update 

roles  .discriminatc(@function)  .action(expunge)  .updatc(newvalue) 
.old(keycd-discrimination)  .ncw(  keyed-discrimination) 
constraints  discriminate.op = .oJd.two  A  .action.key  =  .old.one 
A  .new.two=.update.new  A  .new.one  =  .old.one 
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3.  FUNCTIONS  AND  RELATIONS 

Type  function  specialization  object 

Type  bisection  specialization  function 
definition  instanccfbijcction,/')  =  [  instance! function, F) 

A  Vxy  ( apply(/-» =apply(/j»)  Dx=y  J  ] 

Type  predicate  specialization  function 

definition  instance(predicate,F)  =  [  instance! function,/)  A  rangc-ty pe( F)= boolean  ] 

Function  domain-type :  function  ~*  type 
properties  VFx  { apply(F,x)*  undefined  D  instance(domain-type(F),x)  ] 

Function  range-type:  function-*  type 

properties  VFx  [  apply(F,x)* undefined  D  instancc(range-typc(F),apply(F,x))  J 
f  unction  domain :  function  -*  set 

definition  S=domain(F)  s  Vx[(x€  S)  *-*  apply(F,x)*undefined] 

Function  range :  function  -*  set 

definition 5  =  range!  F )  =  Vx[(x€  5)  «-*  { x*undefincd  A  3y  app]y(Ffi)=x]] 

3.1  Input-Output  and  Test  Specifications  with  Functions 

lOspec  ©function  /  .op( function)  .inputf object)  =>  .output! object) 
preconditions  (.input  e  domain(.op)) 
postconditions  apply(.op,.input) = .output 

lOspec  newarg  /  .old(function)  .arg(objcct)  .input( object)  =*>  ,new( function) 
preconditions  instance!  domain-type!  .old), .arg)  A  instancc(rangc-tvpc(.old).input) 
postconditions  apply!. ncw,.arg) = input 

A  Vxj’f  apply(.old,Jr)=,v  A  x*.arg  D  app!y(.new,x)=>'J 
A  domain-typc(.new)=domain-typc(.old)  A  range-typc(.ncw)=range-type(.old) 

lOspec  new  value  /  ,old( function)  .value(object)  .input(object)  =*>  .new(function) 
preconditions  instancc(range-typc(.old), .value)  A  instance! range-typc(.old),. input) 
postconditions  Vxf  apply!  .old,x)=. value  O  apply(.new.x) = .input  ] 

A  Vxj[  apply(.old,x)=j'  A  y*  .value  D  apply(.ncw,x)=>’] 

A  Vxy[  apply{.ncw.x)=yO  apply!  ,old,x)=.j’V  j  apply(.old.x)=. value  A  y=.input]  J 
A  domain-typc(.ncw)=domain-type(.old)  A  range- typc( .new) = rangc-type(.old) 

Test  ©predicate  /  .criterion! predicate)  .input(objcct) 
condition  apply(.critcrion,.input) = true 
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3.2  Binary  Functions 

Type  binfunction  specialization  object 
Type  binrel  specialization  binfunction 

definition  instancc(binrc1,F)  =  [  instancc(binfunction,F)  A  binrange-typc(F)= boolean ) 

Function  argtype-one :  binfunction  type 

properties  VFxy  [  binapply(F,x,y)*undefincd  3  instance(argtype-one<F),x)  J 

Function  argtypc-two :  binfunction  -*  type 
properties  VFxy  [  binapply(F,x,y)*undefincd  3  instance(argtype-two(FXy)  1 

Function  binrange-type :  binfimetion  — *•  type 

properties  VFxy  [  binapplyfF.jcj')^ undefined  3  instancc(bmrangc-type(F),binapply(  F,x,y))  J 

IOspec  ©binfunction  /  .binop(binfunction)  ,one( object)  .twofobject)  =>  .outputfobject) 
preconditions  binapply(.binop,.one,.  two.)*  undefined 
postconditions  binapply(.binop,.one,.two)= .output 

Test  @binrel  /  .critcrion(binrcl)  .one(object)  .two(object) 
condition  binapply(.critcrion,.oncvtwo)= true 


3.3  Partial  Orders 

Type  partial-order  specialization  binrel 
definition  instance(partial-order,F)  =  l  instancc(binrel,F) 

A  argty pc-onc( F ) = argty pe-two( F  ) 

A  Vx  [  x*  undefined  3  binapply(F,x,x)=true  ] 

A  Vxy  [  binapply(F.xj')  =  true  3  binapply(F,y,x)=  false  ] 

A  Vxj  z  [  binapply(F,x,y)=true  A  binapply(F,y,r)= true  3  binapply(F,x,z) = true  J  ] 

Type  total-order  specialization  partial-order 
definition  instanceftotal-ordcr.F )  =  [  instanccfpartial-order.R  ) 

A  Vxy  [[  instance(argtype-one,x)  A  instanccfargtypc-twoj’)] 

3  ( binapply(F,xty)= true  v  binapply(F,y,x)=true  ]  ]  J 

Function  top:  partial-order  -*  object 
definition' x = top(  R  )  =  Vy  binapplyf  Rj,x) = true 

Function  bottom:  partial-order  -»  object 
definition  x = bottomf  R )  s  Vy  binapply(/?,x,y)  =  tnie 


1 
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3.4  Algebraic  Binary  Functions 

Type  algcbraic-binfunction  subtype  binfunction 
definition  instancc(algcbraic-binfunction,F)  =  [  instancc(binfunction,F) 

A  argtypc-onc(F)  =  argtype-two{F)  A  argtypc-two( /•)  =  binrangc-type(F)  ] 

f  unction  identity :  algcbraic-binfunction  -*  object 
definition  e=idcntity(F)  =  [  instance(binrange-typc(F),F) 

A  Vx[  instance(binrange-type(F),jr)  3  binapply(F,jr,F)=x  A  binapply(F,e,x)=jr]  ] 

Predicate  commutative :  algcbraic-binfunction  -*•  boolean 
definition  commutative(F)  =  Vxy  binapply(F,jf,>)= binapply(F»y,x) 

Predicate  associative :  algebraic-binfunction  — ►  boolean 
definition  associativc(F)  =  Vxyz  binapply(F,binapp}y(F,x,y),z)=binapply(F,x,binapply(F,y,z)) 

3.5  Aggregative  Binary  Functions 

Type  aggrcgativc-binfunction  subtype  algebraic-binfunction 
definition  instance(aggrcgative-binfunction,F)  =  [  instance(algebraic-binfunction,F) 

A  associative(F)  A  commutativc(F)  A  identity! F )* undefined  ] 

Binfunction  plus:  integer  X  integer  -*  integer 
properties  instance(aggrcgative-binfunction.plus)  A  identity(plus) = 0 

Binfunction  times:  integer  X  integer  -*  integer 
properties  instancc(aggregative-binfunction, times)  A  idcntity(times)=  1 

Binfunction  union :  set  X  set  -*  set 

properties  instariccfaggregativc-binfunction, union)  A  empty(idcntily(union)) 
definition  U=  union(S,7)  =  Vjt  |  (x  C  U)  **  [  (jc  €  S)  V  (or  €  T)  J  ] 

Binfunction  intersection :  set  X  set  -+  set 

properties  instance(aggrcgativc-binfunction, intersection)  A  universal(idcntity(intcrsection)) 
definition  U=  intcrscction(5,7)  =  Vx  [  (*  €  U)  *-*  [  (x  €  5)  A  (x  £  T)  ]  ] 

Binfunction  greater:  integer  X  integer  -» integer 
properties  instance! aggrcgativc-binfunction, greater)  A  idcntity(grcatcr)= minus-infinity 
A  Vv  binrcl>binchoice(lc,s)= greater 
definition  ft  =  greater!/,/)  =  [  [/=  ft  *-»  lc( ij)  ]  A  [  /=  ft  «-*  1c (/,/)  ]  ] 
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Binfunction  lesser:  integer  X  integer  -•»  integer 
properties  instanccfaggrcgative-binfunction, lesser)  A  idcntity(lcsser)=  infinity 
A  V$binrebbinchoicc<ge,s)=lesser 
definition  k= lcsserf/,/)  =  [  [j=  k  «-*  ge(y)  ]  A  { /=  k  «-*  ge(/,0  ]  ] 


3.6  Composed  Functions 

DataPIan  co  -used- functions 
roles  .oneounction)  .two( function) 

constraints  range-type(.one)=domain-type(.two)  A  subset(range{.one),domain(.two)) 

DataPIan  hashing  specialization  composed-functions 
roles  .one(  function)  .twofirredundant-scquence) 

DataOverlay  composcd>funct ion :  composed-functions  -»  function 
definition  F=  composed)  function(O)  s 

(domain-typc(F)=domain-typc((unction(composcd-functions(C,s).one,j)) 

A  range-typc(/’)=range-type<function(composcd-functions(0).two,s)) 

A  Vjt  appIy(/'»=apply(funcdon(composed-ftinctions(0).two,s), 

apply(ftinction(composed-functions(C,s).one,s)x))l 

TemporalOverlay  coinposcd>@function :  composed-applics  -»  ©function 
correspondences  c''mposed-@functions.onc.input = @function.input 

A  composed) function(composcd-@fimctions.composite) = ©function.op 
A  composed-®  functions.two.output = @  function.output 
A  composed-® fu nctions.onc.i n = @ fu  nc tion.in 
A  composcd-@functions.two.out= ©function.out 

TemporalPlan  coniposed-@functions 
roles  .compositc(composcd-functions)  ,onc(@function)  .two(@function) 
constraints  .composite.onc  =  .onc.op  A  .composite.two  =  .two.op  * 

A  .onc.output=.two.input  A  cflow(.onc.out,.two.in) 

TemporalOverlay  ncwvaluc-compositoncwvaluc :  newvalue-composite  -»  newvalue 
properties  V P  [  instancc(newvaluc-compositc(/>))  D 

[  instancc(j» newvalue, /’.action)  «-»  instancc(#newvaIue,ncwvaIue-compositc>ncwvaIuc(/’)]  J  J 
correspondences  ncwvaluc-compositc.action.  value = ncwvalue.value 
A  ncwvaluc-compositc.aclion.input= newvaluc.input 
A  composed>function(ncwvaluc-compositc.old)= ncwvalue.o1d 
A  composcd>function(ncwvalue-compositc.new)= ncwvalue.new 
A  ncwvaluc-compositc.action.in  =  ncwvaiue.in 
A  ncwvaluc-compositc.action.out  =  ncwvaluc.out 
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TemporalPlan  ncwialue-coniposite 

roles  .action(  new  value)  .old(composcd-functions)  .ncw(composcd-functions) 
constraints  .old.one  =  .new.one  A  .action.old  =  .old.two  A  action.new  =  .new.two 


3.7  Updating  a  Bijection 

TemporalOverlay  newarg>ncwvalue :  ncwarg-bijcction  -*  ©function+newvalue 
properties  V N  [  instance(ncwarg-bijcction,iV)  3 

[  instancc(#newarg,/V)  *+  instance(#newvalue,newarg>newvalue(A,).update)]  J 
correspondences  ncwarg-bijection.old  =  @  function+ncwvaluc.update.old 
A  ncwarg-bijcction.arg=@function+ncwvaluc.action.input 
A  ncwarg-bijcction.input  =  <a:function+ncwvalue.update.input 
A  newarg-bijection.ncw=<fcftinction+newvaluc.update.new 
A  newarg-bijeciion.in  =  @functiorn-newvaluc.action.in 
A  newarg-bijcction.out= @function+newvaluc.update.out 


lOspec  newarg-bijection  /  .old(bijection)  .arg(object)  .input(object) 

=>  .output(bijection) 


specialization  newarg 


TemporalPlan  @(unction+ncwvalue 
roles  .action(C«function)  .updatc(ncwvalue) 
constraints  instancc(bijection,.action.op)  A  .action.op  =  .update.old 

A  .action.output  =  .update. value  A  cflow(.action.out,.update.in) 


3.8  Binary  Relations  as  Predicates1 

DataOverlay  binrel+two>predicate :  binrel+two  predicate 
definition  />=binrcl+two>prcdicatc(5,j)  = 

V x  ( apply( P,x) = true  *■»  binapply(binrel(binrel+two(Z?,j).op,s),jr,binrcl+two(/?,s).two)=true] 

DataPlan  binrel+two 
roles  .op(binrcl)  ,two(()bject) 
cons/ruin/sinstancc(argtype-two(.op),.two> 


1.  See  Fig.  A- J. 
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rmporu/Over/oy  @binrel>prcdicate:  ©binrel-composite  -*■ ©predicate 
correspondences 

binrcl+two>predicatc((a1binrel-composite.compositc)=@predicate.criterion 
A  (rt  binrcl-compositc.if.onc  =  ©predicate.input 
A  ©binrcl-compositc.if.in  =  @prcdicate.in 
A  (a  binrel-composite.if.succccd  =  ©predicate.succeed 
A  (a binrel-composite.if.fail  =  ©predicate.fail 

T emporalPlan  @binrel-composite 
roles  .compositc(binrcl+two)  .iff@binrel) 
constraints  .composite.op = .if.criterion  A  .composite.two  =  .if.two 

DataOverlay  integer>prcdicate :  integer  -*•  predicate 
definition  /'=  intcger>prcdicate(/,s)  =  Vy[  apply(/>j)=  true  «-*  ;=integer(/,s)) 
properties  V  Bs  [  [  binrel+t wo(  5,5).op  =  cq  A  insLance(intcger,binrel+two(Z?,s).two)  J 
3  binrel+two>predicatc(/?,i-)=integer>predieate(/?.two,5)] 

3.9  Functions  as  Binary  Relations 

Type  many-to-one  subtype  binrel 
definition  instance(many-to-one,ft)  =  [  instance(binrel,/?) 

A  Vxyi f  binapply(/?,jt,y)= true  A  binapply( R.x.z) = taie  Dy-z]] 

DataOverlay  function>binrcl :  function  -»  many-to-one 
definition  =function>binreI (F,s)  s  Vxy  f  appIy(function(/r,5),jr)=;' *■*  binapply(/?,x^)= true  ] 

3.10  Functions  as  Predicates1 

DataOverlay  function+two>prcdicate :  function+two  -+  predicate 
definition  P-  function*  two  >prcdicate(C,s)  = 

Vjt  (apply(/>,jr)  =  true  ♦+  apply{function(function+two(C,j).op,j),jr)=funciion+two(C,5).two] 

DalaPlan  function+two 
roles  .op(  function)  .twofobject) 
constraints  instance(rangc-typc(.op),.two) 


1.  See  Fig.  A-4. 
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TemporalOverlay  @function+equal?>predicate :  @;function+equal  -»  ©predicate 
correspondences  function+two>prcdicatc(<afunction+cqual.compositc)  =  ©predicatc.criterion 
A  ©  function+cquaLaction.input  -  Caprcdicate.input 
A  ©  funciion+cqual.action.in  =  ©  prcdicate.in 
A  ©function+cqual.if.succced  =  ©  prcdicatc.succeed 
A  ©flinction+equal.if.fail  =  ©prcdicate.fail 

Temporal  Plan  ©function  f  equal? 
roles  .composite(function+two)  .action(@function)  .iff  equal?) 
constraints  .composite.op  =  .action.op  A  .compositc.two=.if.two 
A  .action.output=.if.one  A  cflow(.action.out,.if.in) 

Test  equal?  /  .onc(object)  .two(object) 
condition  .one = .two 

3.11  Function  and  Predicate  Composites1 

DataOverlay  function+predieatoprcdieate :  function+ predicate  -»  predicate 
definition  P=  function+predicatoprcdicatefO)  = 

V.r  [  applyf/V*)  =  true  «-+  apply(predicate(function+predicatc(C,s)-critcrion,s) 

,apply(function(function+predicate(C,s).op,s),Jir))  =  true  ] 


DataPlan  function+prcdicate 
roles  ,op(  function)  .criterion(predicate) 
constraints  rangctypc(.op) = domain-type(  .criterion) 

TemporalOverlay  @funetion+predicate>predicate :  ©function+prcdicate  — *  ©predicate 
correspondences 

function+prcdicate>predicatc(@>function+predicate.composite)=@predicatc.criterion 
A  @fiinction+prcdicate.action.input  =  © prcdicate.input 
A  @function+prcdicate.action.in = ©prcdicate.in 
A  @function+predicatc.if.succccd  =  ©prcdicatc.succeed 
A  @function+prcdicatc.if.fail  =  ©prcdicate.fail 

TemporalPlan  ©function+prcdicate 

roles  .compositcffunction+prcdicatc)  .actionf©  function)  .iff ©predicate) 
constraints  .composite.op  =  .action.op  A  .compositc.critcrion = .if.criterion 
A  .action.output  =  .if.input  A  cflow(.action.out,.if.in) 


/ 


I.  Sec  Fig.  A-5 
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Figure  A-5.  Testing  a  Predicate  Implemented  as  a  Function  and  Predicate  Composite. 
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3.12  Complementary  Predicates 

DataOverlay  complement :  predicate  -*  predicate 
properties  V.m[  complements)  =  complements)  D  predicate's)  =  predicate's)  ] 
definition  Q- complement's)  =  Vx [ apply((?,x)  =  true  «-+  apply(predicatc(/\s),x)  =  false] 

7V»»pora/0ver/m'@prcdicatc>con,plement :  ©predicate  -»  ©predicate 
properties  Vjrvs[©predicaic>complemcnt(x,s)=@predicatc>complemcntO',s)  O  x-y] 
definition  .V=@predicate>complement(7')  = 

[  ^.criterion = complement(  ^criterion,  f.in) 

A  5.input=  f.input  A  S.in=  T.in 
A  S.succccd  =  T.fail  A  S.fail  =  T.succced  ] 

3.13  Choice  Functions1 

Type  binchoicc  subtype  algebraic-binfunction 
definition  instancc(binchoice.F)  =  [  instance(binfunction,F) 

A  Vxy  [  binapplytf'.jcj1)  =  x  V  binapply(F,xj>) = y  ]  ] 

DataOverlay  binrebbinchoice :  binrel  -+  binchoice 
properties  V Rf's[  [  F=  binrcbbinchoice(/?,s)  A  instance(partial-order,binrcl(/f,s))j 

3  [  instance(aggregativc-binfunctiort,/-')  A  Vx  [  bottom(binrcl(/?,s),x)  +■+  x= idcnliiy(f))  1 1 
definition  F=binrcbbinchoicc(/?,s)  s  Vxj  [  binapply(binrel( /?,s),xj')  =  true  *-*  binapply(/',xj)=^] 

TempomlOverlay  t&binrebchoicc:  ©binrel+join  -+  (©choice 
correspondences 

binrcl>binchoicc(©binrcl+join.if.critcrion) = ©choicc.binop 
A  ©binrcl+join.end.output= @choice.output 
A  ©binrcl+join.if.in  =  ©choice.in 
A  ©binrcl+join.end.out=@choice.out 

IOspec  ©choice  /  .binop(binchoice)  .one(object)  .two(objcct)  =>  .output(objcct) 
specialization  ©bin  function 

TemporalPlan  ©binrel+join  specialization  cond 
roles  .ift©binrel)  .then(in+out)  .clsc(in+out)  .cnd(join-output) 
constraints  .if.two =.end.succced-input 
A  ,if.one=.end.fail-input 


1.  See  Fig.  A-6. 
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4.  SEQUENCES 

Type  sequence  subtype  function 

definition  instance(  sequence, F )  =  ( domain-type(F, natural)  a  length(F)*  undefined  J 
Type  irredundant-sequence  subtype  bijection  sequence 
Type  finite-sequence  subtype  sequence 

definition  instancc( finite-sequence, S')  =  [  instance(scquence,S)  A  finitc(lcngth(S))  J 

4.1  Relations  on  Sequences 

Function  length :  sequence  -*  cardinal 

definition  L=lcngth(S)  =  V/  [  apply(S,0*undefined  *-*  [  instance(natural,0  A  lef/,F)  ]  ] 

Binrel  index :  sequence  X  natural  -*  boolean 
definition  indcxfS,/)  s  [  instance(natural,0  A  le(/,length(S))  ] 

Function  first:  sequence  -*  object 
definition  firstfS)  =  applyf.S’.l) 

Function  last:  finite-sequence  -*  object 
definition  lastfS)  =  app!y(S,length(S)) 

Function  but  last:  finite-sequence  -*  finite-sequence 
definition  7"=  butlasl(.S)  =  [length(6,)=oneplus(length(7’)) 

A  V/>[indcx(r,/)  D  ( apply(S,/)=x  *-»  apply(T,0=xJ]  J 

Function  reverse:  finite-sequence-*  finite-sequence 
properties  VS  reversc(rcvcrse(5))= S 
definition  F=  revcrsc(.V)  =  [  length(S)=lcngth(F) 

A  V  i  apply(S,0 = apply( r,oneplus(minus(length(S),/)))  ] 


4.2  Input-Output  Specifications  with  Sequences 

lOspec  term  /  .op(sequencc)  .input(natural)  =»  .output(object)  specialization  ©function 
preconditions  indcx(.op,.input) 

lOspec  newterm  /  .old(scquence)  .arg(natural)  .input(object)  =>  .ncw(scqucnce) 
specialization  newarg 
preconditions  index(.old,.arg) 
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lOspec  #newtcrm  /  .old/sequence)  .arg/ natural)  .input(objcct)  =>  .new(sequence) 
specialization  newtcrm  #ncwarg 

lOspec  truncate  /  .input(sequence)  .criterion(predicate)  =>  .output(finite-sequence) 
preconditions  3/  apply/.criterion,apply/.input,0) = true 
postconditions 

V/[index(.output,/)  +»  V/[  le(/,0  3  apply(.criterion,apply(.input1/))= false  ]  ] 

A  V/[  index/.output,0  3  apply(.output,/)=apply(.input,/)l 
A  apply(.critcrion,apply(.input,oncplus(length(.output))))=true 

lOspec  truncate-inclusive  /  .input(seqence)  .criterion(predicate) 

=>  .output(finite-sequence) 

preconditions  3  /  apply(.critcrion,apply(.input,/))= true 
postconditions 

V/[index(.output,0  ♦*  Y/[lt(/,i) 

3  apply/ .criterion, apply(.inputj))= false  ]  ] 

A  V/[  index( .output,/)  3  apply(.output,/)=apply(.input,/)l 
a  apply(.critcrion,last(.output)) = true 

lOspec  earliest  /  .input(sequcncc)  .criterion(predicate)  =>  .output(object) 
preconditions  3  i  apply(.criterion,apply(.input,/))=true 
postconditions  apply(  .criterion,.output)= true 
A  3/ 1  apply(.input,/)=. output 

A  V/[  lt(/,i)  3  apply(.criterion,apply(.inputt/)) = false )  ] 

lOspec  iterate  /  .input(iterator)  =>  .output(sequence) 
postconditions  range-type(  .output) = argtypc-one/.input.op) 

A  first(.output)=.input.seed 

A  V/[  apply(.ouiput,oneplus(0)=successom(£,generator>digraph(.input),.inpuLseed)l 

lOspec  map  /  .input(sequcnce)  .op/function)  =>  .output(scquence) 
preconditions  subset/ rangc(. input), domain(.op)) 
postconditions  range-type(.output)=  range-type(.op) 

A  lcngth(.input)= length/  .output) 

A  V/(  index( .input,/)  3  apply(.output,0=apply(.op,apply(.input,/))] 

4.3  Segments 

DataOverlay  scgnicnt>scqucncc :  segment  -*  sequence 
definition  Q = scgment>scqucnce/(7,j)  a 

( length/ 0  =  diffcrcncc(natural(scgment(t7,.v).uppcr,i),natural(scgment(/7,s).lowew)) 

A  V/[  index/ 0,0  3  apply/ 0, 0 = apply/ segment/ f7.s).base,plus< ;,naturaf(scgnicnt((7,s).!owcr,s)))  J  ] 
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Data  Plan  segment 

roles  .base(scquence)  .lower(natural)  .uppcr(natural) 
constraints  indcx(.base,.lower) 

A  index(.basc,.upper)  A  le(.lower,.upper) 

DataPlan  upper-segment  specialization  segment 
roles  .base<sequcnce)  .lowcr(natural)  .uppcr(natural) 
constraints  .upper = length(.base) 

DataPlan  lower-segment  specialization  segment 
roles  .basc(scquence)  .lower(natural)  .upper(  natural) 
constraints  .lower  =  1 

5.  LISTS 

Type  list+nil  uniontype  list  nil 

Type  finite-list  specialization  list  finite-single-recursion 

Type  finitC'list+nil  uniontype  finite-list  nil 

DataPlan  irredundant-list  specialization  list 
definition  instancc(irrcdundant-list,Z.)  5  ( instance(listX) 

A  tail*(/„A/)  D  hcad(list(A/,s))*£.headJ 
A  instance(irredundant-list,list(L.tail,s))  ] 

lOspec  push  /  .old(list+nfl)  .input(object)  =>  .new(list) 
specialization  old+input+new 
postconditions  head(.new)= .input  A  tail(.new)=.old 
A  oneplusClength(.old)) = length(.new) 

IOspec  pop  /  .old(list)  *=>  ,ncw(Iist+nil)  .output(object) 
postconditions  hcad(.old)= .output  A  tail(.old)= .new 

lOspec  ©head  /  .op(function)  ,input(list)  =*  .output(object) 
specialization  ©function 
preconditions  .op  =  head 

lOspec  ©tail  /.  .op( function)  .input(list)  =>  .output(iist+nil) 
specialization  ©function 
preconditions  .op = tail 


/ 
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5.1  Upper  Segment  as  List 

DataOverlay  uppcr-scgmcnt>list :  upper-segment  -*  list+nil 
definition  L=uppcr-scgment>list((7,s)  s 

[[  L=nil  <-+  lcngth(segmcnt(G,s).basc)  =  natural(scgmcnt(G,s).lower,s)] 

A  [  instancc(list,L)  3 

A  Lhead=apply(sequcnce(scgment(G,s).base,s),natural(segment(G,s).lower,j)) 

A  3//{  instance(upper-segment,//) 

A  scqucncc($egment(  G,s).base.s) = scquence(segment(//,s).base,s) 

A  oneplus(natural(segment(G,s).lower,s))=natural(segment(//,j).lower,j) 
A  Ltail  =  uppcr-segment>list(//,s)  ]  ]  ] 

TemporalOverlay  bunip+updatc>push :  bump+update  -►  push 
correspondences  uppcr-scgmcnt>1ist(bump+updatc.old) = push.old 
A  bump+update.update.input = push. input 
A  uppcr-segmcnt>list(bump+update.new)=push.new 
A  bump+update.bump.in=push.in 
A  bump+updatc.update.out= push. out 

TemporalPlan  bump+update 

roles  .bump(Cac)ncminus)  .update(ncwterm)  .old(upper-scgment)  .ncw(upper-segmcnt) 
eo/jj/rai/i«cflow(.bump.out,.update.in) 

A  ,old.1owcr=.bump.input 
A  .bump.output=.updatc.arg 
A  update.o!d=.old.base  A  .update.new=.new.base 
A  .ncw.iower=.bump.output 

IOspec  @oncminus  /  .op( function)  .input(integer)  =»  .output(integer) 
preconditions  .op  =  oncminus 

TemporalOverlay  fetch+bump>pop :  fetch+bump  -*  pop 
correspondences  uppcr-scgment>list(fctch+bump.o1d) = pop.old 
A  uppcr-scgmcnt>list(fctch+bump.ncw)= pop.new 
A  fctch+biiinp.fctch.output = pop.output 
A  fctch+bump.fctch.in=pop.in 
A  fetch+bump.bump.out=pop.out 

TemporalPlan  fetch+bump 

roles  .fetch(tcrm)  .bump^oncplus)  .old(uppcr-segmcnt)  .ncw(uppcr-scgment) 
constraints  .old. base  =  .fctch.op  A  ,old.lowcr=.fetch.input 
A  .old.lowcr=.bump.input 
A  .new.base  =  .old.basc  A  .ncw.lower=.bump.output 

IOspec  (goneplus  /  ,op( function)  .input(intcger)  .output(intcgcr) 
preconditions  .op = oncplus 
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6.  DIRECTED  GRAPHS 

DataPlan  digraph 
roles  .nodes(set)  .cdgc(binrcl) 

DataPlan  tree  specialization  digraph 
properties  VG  instancc{trec.G)  o  Vxy[  root(G,x)  A  rootlGj')  D  x=y] 
roles  .nodes(set)  .cdgc(binrel) 

definition  instance!  trec.G)  =  [  instance(digraph,G)  A  3x  [  root(G,x)  ]  A  Vx  [-■successor*! G,x,x)  ]  ] 

DataPlan  bintrcc  specialization  tree 
roles  .nodcs(sct)  .cdge(binrcl) 
definition  instancc(bintree,r)  =  [  instancc(tree,7') 

A  Vx  [  nodc(7,x)  A  -itcrminal(7',x)  D  size(successors(7',x))=2 )  ] 

DataPlan  thread  specialization  tree 

properties  VT  instance!  thread,  T)  D  [  Vxy  [  terminal!  7»  A  terminal(7»  D  x=y] 

A  'ixyz [  successor T,xy)  A  successor!  7;  zjj  D  x=z]] 
roles  .nodes(set)  .edge(many-to-one) 


6.1  Relations  on  Directed  Graphs 

Binrel  noie:  digraph  X  object  -»  boolean 
definition  node(G,x)  =  (x  €  G.nodes) 

Trirel  successor:  digraph  X  object  X  object  -*•  boolean 
definition  successor  G,xy)  =  [  node((7,x)  A  nodc(Gj’)  A  binapply(G.edge,xj') = true  1 

Binfunction successors:  digraph  X  object  -*  set 
definition  S= successors! G,x)  =  Vj/[(p€  S)  «■*  successor!  G,xj>) ] 

Trirel  successor*:  digraph  X  object  X  object  -*  boolean 
definition  successor*! G,xj')  =  3!succcssom(i,G,x,,y) 

Quadrel  successor™ :  natural  X  digraph  X  object  X  object  -*•  boolean 
definition  succcssorn( i, G.xj')  — 

1 1  /=  1  A  succcssor(G,xj')  ] 

v  3z  [  successor! G,x,z)  A  succcssom(oneminus(/).G,zj')  ]  J 

Binrel root:  digraph  X  object  -»  boolean 
definition  root(G.x)  =  'iy[  (nodc(Gj')  A  x*y)  D  successor*!  G.xj’)  ] 

Binrel  terminal :  digraph  X  object  -*  boolean 
definition  terminal!  G,x)  &  [  nodc(G.x)  A  ->3>’  successor G,x,y)) 
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Binrel subgraph:  digraph  X  digraph  -*  boolean 
properties  instancc(partial-ordcr, subgraph) 
definition  subgraph((7,//)  s 

1  Vxy[  successor!  C.jrj-)  3  successor!//,^)] 

A  nodc(G,jr)  A  nod^Gj-)  A  successor {H,xy) 
D  successor!  G,xy)  ]  ] 


6.2  Input-Output  Specifications  with  Directed  Graphs 

lOspec  digraph-add  /  .old(digraph)  .input(object)  =>  .ncw(digraph) 
specialization  old+input+new 
postconditions  (.input  €  .new.nodes) 

A  Varp[  [  X*  .input  A  .p*  .input 

A  isuccessor(. new, input)  A  -isuccessor(.newj»,. input) 

A  -isucccssor(.new,. input, jc)  A  -isuccessorf.new.jnput^p)  ] 

D I  successor(.new,xj')  «-+  successor(.oId,jt^)  J  ] 

IOspec  digraph-remove  /  ,old(digraph)  .input(object)  =>  .new(digraph) 
specialization  old+input+new 
postconditions  (.input  €  .new.nodes) 

A  Vxy  [  x*  .input  A  y*  .input  3  [  successor!. new, oy>)  ++  successor(.old,x,p)  ]  J 
A  Vac  [  successor(.old,jr,.input) 

D  Vp  [  successort-new,^)  +♦  successor(.old,.inputo')  ]  J 

IOspec  digraph-find  /  .universc(digraph)  .criterion(predicate)  =>  ,output(object) 
preconditions  3*  [  node(.universe,jt)  A  apply(xritcrion,jr) = true  ] 
postconditions  nodc(.universc,.output)  A  apply(xriterion,.output)=true 

6.3  Generators 

Data  Plan  generator 
roles  .sccd(object)  .op(binrel) 

constraints  instance(argtype-one(.op),.sced)  A  argtype-one(.op)=argtype-two(.op) 

DataPlan  iterator  specialization  generator 
roles  .sced(object)  .op(tr.any-to-one) 

DataOverlay  generatoodigraph :  generator  -»  digraph 
properties  VRs  root(generator>digraph(/?,s\gcnerator(/?,j).seed) 
correspondences  gcncrator.op  =  digraph.cdgc 

A  transitivc-closurc(gcncrator)=digraph.nodes 


j 

i 
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DaiaOverlay  transitive-closure :  generator  -*  set 
definition  T  =  transitive-closure! /?,s)  = 

Vx[(jt€  7)  *♦ 

( jr=generator(^,j).seed  v  3y[(y€  T)  A  apply(ftjnction(generator(/?,j).op,s)j')=xJ J J 

Datastructure  natural-iterator  instance  iterator 
components  .seed  =1  .op = oneplus 

Datastructure  natural-thread  instance  thread 
properties  Vsgencrator>digraph(natural-iterator,s)=natural-thread 
components  .nodes = naturals  .edge  =  function>binrel(oneplus) 

DaiaOverlay binary>generator :  binary-generator-*  generator 
properties  VBGs[  <?=binary>generator(Z?,s)  3  instance(bintree,gencrator>digraph((7,i))] 
correspondences  binary-generator.secd  =  gcnerator.seed 

A  binrel-union(function>binrel(binary-generator.left), 

function>binrel(binary'generator.right))=generator.op 

Binfunction  binrel-union :  binrel  X  binrel  -*  binrel 
definition  T  =  binrel-union(fl,S)  s 

Vjt y  [  binapply(7’,jcj')= true  *-*  [  binapplyf/?,^) = true  v  binapp]y(^,jcj')= true  ]  ] 


6.4  Truncated  Directed  Graphs 

DataPlan  truncated-digraph  > 

roles  .base(digraph)  .criterion(predicate) 
constraints  Vjc  ( nodc(.base.x)  3  [  apply(.criterion,Jr)=true 

v  3y  [  successor*!  .base.x^’)  A  apply!  .criterion,y)= true] 
v  3>-  [  successor*(.base,j,jr)  A  apply(.criterionj’) = true  ]  ]  ] 

DataPlan  truncated-tree  specialization  truncated-digraph 
roles  .base! tree)  .critcrion(predicate) 

DataPlan  truncated-thread  specialization  truncated-tree 
properties  V7s[  instancc(truncatcd-thrcad,r)  3 

3jc  [  nodc(digraph(7’.basc,r),jr)  A  apply(prcdicate(  7'.critcrion,s),jf) = true  ]  ] 
roles  .basc(  thread)  .critcriontpredicate) 
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6.5  Finite  Subgraphs 

DataOverlay  truncated>digraph :  truncated-digraph  -*■  finite-digraph 
properties  V  TFs  [  F-  truncated>digraph-inclusive(  T,s)  D 

[  instance(thrcad,digraph(truncated-digraph(r,s).basc,r))  **  instancc(thread,/r)  ] 

A  ( instance!  tree, digraph(truncatcd-digraph(7',s).basc,s))  *+  instance(tree,F)]] 
definition  F=  truncated>digraph(7’,s)  = 

[  subgraph(/\digraph(truncatcd-digraph(7',s).base,s)) 

A  Vjr[  node(/»  ( nodc(digraph(truncated-digraph(r,s).base,s),jc) 

A  3x1  succcssor*(digraph(truncatcd-digraph(7’,5).base,sXjrj') 

A  app!y(prcdicate(truncated-digraph(  7».criterion,s),x)  =  true  ] 

A  ->3 z\ succcssor*(digraph(truncated-digraph(7',s).base,r),z,jr) 

A  apply(predicatc(truncated-digraph(7,5).criterion,i),z)= true  ]  J  ]  ] 

DataOverlay  truneated>digraph-inclusivc :  truncated-digraph  -*  finite-digraph 
properties  VTFs[  F=  truncated)  digraph -inclusive!^)  D 

[  instance!  thread, digraph(truncated-digraph(7",s).base,5))  ♦♦  instance!  thread, F)  ] 

A  [instance! tree, digraph! truncated-digraph( 7’,r).basc,5))  *+  instanceOree.F)]] 
definition  /r=truncated>digraph-inclusive!7’,s)  = 

[subgraph! /-;digraph!tnincated-digraph!7’,i).base,s)) 

A  Vjt  [  node(/’,jr)  *+  [  node! tru ncated > digraph! T,s),x) 
v  3>’[  nodc(truncated>digraph(7’,s)ty) 

A  successoddigraph! truncated-digraph! 7’,s).base,s)vp,jr) 

A  apply!predicatc(  truncated-digraph!  7',s).critcrion,r),jr)  =  true  ]  ] )  ] 

DataPlan  finite-digraph  specialization  digraph 
roles  .nodes! finite-set)  .edgc!binrel) 


6.6  Trailing  Plans 

TemporalPlan  trailing  extension  single-recursion 
roles  .current! object)  .prcvious(object)  .tail(trailing) 
constraints  .current = .tail.previous 

TemporalPlan  traiiing-search  extension  trailing  iterative-search 
roles  .currentfobjcct)  .prcvious!objcct)  .exit!cond)  .tail(trailing-search) 
constraints  insumccQoin-two-oulputs,.cxit.cnd) 

A  .current =.cxit.if.input  A  .previous =.cxit.cnd.succccd-input-two 
A  .tail.cxitend.output-two=  .exitend.fail-input-two 
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6.7  Trailing  Generation  and  Search 

Temporal  Plan  trailing-generation+scarch  extension  iterative-generation  trailing-search 
roles  .current(objcct)  .previous(object)  .exit(cond)  .action(@function) 
.tail(trai!ing-generation+search) 
constraints. current  =  .action.output  A  .previous =.action.input 

lOspec  internal-thread-find  /  .univcrse(thread)  .criterion(predicate) 

=*  .output(object)  .previous(object) 

extension  digraph-find 

preconditions  Vx  [  root(. universe, x)  D  app!y(.criterion,x)= false  J 
postconditions  successor(.universe,.previous,.output) 

TemporalOverlay  trailing-gcncration+search>find :  trailing-iteration+search  — »  internal-thread-find 
correspondences 

gencrator>digraph(tcmporal-itcrator(trailing-gcncration+search)) 

=  intcmal-thread-find.universe 

trailing-gencration+search.exit.if.criterion  =  internal-thread-find.critcrion 
trailing-generation+search.exit.end.output=intcrnal-thread-find.output 
trailing-generation+search.exit.end.two  =  internal-thread-find.previous 
trailing-gcncration+scarch.action.in  =  intcmal-thrcad-find.in 
trailing-generation+search.exit.out = intemal-thread-find.out 

6.8  Splicing  Out  of  a  Thread 

Temporal  Plan  spliceout 

roles  .old(itcrator)  .new(itcrator)  .bump(@function)  .splice(newarg) 
constraints  .old.op  =  .bump.op  A  .ncw.op=.splice.out  A  .old. seed = .new.secd 
A  .bump.output=.splice.input 

A  succcssor(gcncrator)digraph(.old),.spIice.arg,.bump.input) 

lOspec  intcmal-thread-rcmovc  /  .old(thread)  .input(object)  =»  .new(thrcad) 
specialization  digraph-remove  old+input+new 
preconditions  ->root(.old,. input) 

TemporalOverlay  spliceout>rcmovc :  spliceout  -*  internal-thrcad-rcmove 
properties  VS [  instancc(#spliccout,5)  *->  instance(#  intcma!-tli read-remove, spliceout>rcmovc(5))] 
correspondences 

generator>digraph(spliccout.old)  =  internal-thrcad-rcmove.old 
A  spliccout.bump.input  =  intcrnal-thread-remove.input 
A  gencrator>digraph(spliceout.new)  =  intcrnal-thrcad-rcmove.new 
A  spliccout.bump.in  =  intcrnal-lhrcad-rcmovc.in 
A  spliccout.splicc.out= intcrnal-thread.remove.out 
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TemporalPlan  spliceout  specialization  spliceout 
roles  .old(itcrator)  .new(itcrator)  .bump(@fijnction)  .splice(#ncwarg) 

lOspec  #internal-thread-rcmove  /  .old(thread)  .input(object)  =>  .new(threaa) 
specialization  internal-thread-rcmove  #old+input+new 


6.9  Splicing  Into  a  Thread1 

TemporalPlan  splicein 

roles  .oId(iterator)  .new(  iterator)  .one(newarg)  .two(newarg) 
constraints  .one.arg = .two.input  A  one.new  =  .two.old 

A  successor(generator>digraph(.old),.two.arg,.one.input) 

l O spec  intemal-thread-add  /  .old(thread)  .input(object)  =>  .new(thread) 
specialization  digraph-add  old+input+new 
postconditions  -»  root(. new, .input) 

A  Vx  [  successor(.new,jr,.input) 

D  Vy  [  successor(.old,Jrj')  «-»  successor(.new,.inputj')  ]  ] 

TemporalOverlay  spliccin>add :  splicein  -»  intemal-thread-add 
properties  VS  l  instance!  #splicein,S)  *♦  instance(#intcrnal-thread-add,splicein>add(.S))J 
correspondences 

generator>digraph(spliccin.old) = intcmal-thread-add.old 
A  splicein.one.arg= intcmal-thread-add.input 
A  gencrator>digraph(splicein.new) = intcrnal-thread-add.new 
A  find+splicein.one.in  =  intemal-thread-add.in 
A  find+spliccin.two.two.out=intemal-thread-add.out 

TemporalPlan  *  splicein  specialization  splicein 
roles  .old(iterator)  .new(iterator)  .one(#newarg)  .two(#newarg) 

IOspec  #intcrnal-thread-add  /  ,old(thread)  .input(object)  =>  .new(thread) 
specialization  internal-thread-add  #old+input+new 


6.10  Labelled  Directed  Graphs 

DataPlan  labelled-digraph 
roles  .spinc(digraph)  .label(function) 
constraint'  subset!  .spine.nodes,domain(.label)) 


Srt  Pi*.  A-7. 
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Figure  A-7.  Adding  an  Internal  Node  lo  a  Ilircad  by  Splicing  In. 
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DaiaPlan  labelled-thread  specialization  labelled-digraph 
roles  .spine(  thread)  .labcl(function) 

DaiaPlan  cdr-thread+car  specialization  labelled-thread 
properties  VPs  [  instancetcdr-thread+car.P) 

D  3jc  [  root!  thread!  Aspine,*),*)  A  list>labelled-thread(dottcd-pair>list(jc,s),s)= />]  ] 
roles  .spine(cdr-thread)  .label(function) 
constraints  .label = car 

DaiaPlan  edr-thread  specials  uion  thread 
roles  .nodcs(set)  .edge(many-to-one) 

constraints set-type(.nodes) = dotted-pair  a  Vs(  binrel(.edge,s)=function>binrel(cdr,s)] 


6.11  Trees  as  Partial  Orders 

DataOverlay  tree>order :  tree  — ►  partial-order+bottom 
properties  VTRs[  /f  =  tree>order( r,s)  D  { root(tree(7',s),bottom(/J)) 

A  [instance(thrcad,trce(r,s))  <-+  instance( total-order,/?)  J  ]  J 
definition  R  =  tree>ordcr(7’,s)  =  Vx>’[binapply(/{,x>y)=truc  <-»  [  x-y  v  successor*(trec(7’,s),acj») ]  ] 

Type  partial-order+bottom  subtype  partial-order 
definition  instance(partial-order+boltom,/J)  =  [  instancc(partial-order,fl)  A  3x  bottom! /?,*)  ] 

6.12  Intervals 

DataPlan  interval 

roles  .base(total-order)  .lowcr(object)  .upper(object) 
constraints  binapply(.basc,.lower,.  upper) = true 

DataOverlay  intcrvabtruncatcd-thread :  interval  -+  truncated-thread 
properties  V/Ts l  r=interval>truncatcd-thrcad(/,s)  3 

interval!  /,s).lower = bottom!  tree  >ordcit  truncated  >digraph(  T,s),s)) 

A  interval! /,j).uppcr=  top!trcc>ordcr(truncatcd>digraph-inclusi vc( T,s),s)) ] 
definition  T  =  interval>truncated-thrcad(/,j)  = 

[  root!  F, interval! /,s).lower) 

A  total-order!interval( /.s).base,j) = trce>ordcr( thread! Abase,*), $) 

A  predicate!  ^criterion,*) = intcger>prcdicatc( interval!  /,s).upper,j)  J 
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7.  LINEAR  STRUCTURES 

DalaOverlay  listxsequcnce :  list+nil  -*  sequence 
properties  V/.Qs[  Q- list>scquence(/,s)  D 
[  length(list+nil(/.,5))  =  length((?) 

A  [  instancc(irredundant-list,list+nil(A,i))  «-»  instance(irredundant-scquence,0  ]  J I 
A  Vxysf  list>scqucncc(jf,j)=list>scquenccO,,s)3  list+nil(jc,s)=list+nil(>',s)] 
definition  £>=list>scquencc{I,.s)  s 

[  [  lcngth(0 =0  «-»  list+nil(Z.,r) = nil  1 
A  [  list(/.,s)^  undefined  O 
[  first(0=list(L,j)Jread 

A  V ix  [apply(0O = x  **  3M[  tailn(oneminus(/),list(Z.,s))= M  A  list( A/,s).head  =  x J  ]  ]  ]  ] 


DalaOverlay  scquencolabelled-thread :  finite-sequence  -*  labelled-truncated-natural-thread 
properties  Vxys  [  sequcncc>labellcd-thread(jr,i)= sequcnce>labelled-thread(>',$) 

3  sequence!*.*) = sequence^,*)  J 
definition  L  =  sequcncc>labellcd-thread(Q,r)  = 
l  function!  /..label, s)= sequencers) 

A  3 T[  digraph(L.spine,s)=truncated>digraph-inclusive(r,j) 

A  predicate!  7xriterion,j) = integcr>predicate(lcngth(scquence(0j)),j)  J  J 

DalaOverlay  list>labcllcd-tliread :  list  — ►  labelled-thread 
definition  T =  list>labellcd-thread(/.,r)  = 

[  Vjc  [  [  jr=list(/.,s)  V  tail*(list( /.,*),*)  ]  *■*  (x  6  7".spine.nodes)  1 
A  7’.spine.cdge=tail  A  /".label = head  J 

DataPlan  labcllcd-truncatcd-natural-thrcad  specialization  labelled-thread 
roles  .spine(  thread)  .labcl(function) 

constraints  3  Ts  [  instance! truncated-thread,  T)  A  T.base = natural-thread 
A  .spine = truncated>digraph-inclusive(7',j) ) 

DalaOverlay  scquencothrcad :  irredundant-sequence  -*  thread 
properties'll QTs[  T=  scquencothrcad! Q,s)  O 

length(sequcncc«?, s)) = sizc(sct( F.nodes,s))  A  terminal! r,last(sequcnce( £>,*)))  ] 

A  Vjys[  sequence>lhrcad(.K,s)  =  scquence>thrcadO’,i)  3  sequencc(ar,j)=scquencc(>’,j)  J 
definition  T=  sequence)  thrcad(0s)  & 

{ root(r,first(scqucnce(0j))) 

A  Vi[indcx(scquence((?,j),0 

.  O  successor!  7", apply(scquencc(0,rXO.apply( sequence! 0,i),oncplus(O))  J  ] 

DalaOverlay  list>thrcad :  irrcdundant-list  -*  thread 
properties  Vjy  j[  list>lhrcad(x,s)=list>thrcad(j',s)  D  list(x,s)=  list(y,s)  J 
definition  7"=  list)  thread!/.,*)  =  V*  ( [  list! /^j).hcad  =  x  *-*  root(r,jr)] 

A  V/jrf  3A/  ( tailn(/,list( /.,*),  A/)  A  A/.hcad  =  x  ]  *+  3j’(  root(7>)  A  successor^  f,7>,x)  J  J  J 
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8.  FLAGS 

DaiaPlan  flag 

roles  .arg(object)  xriterion(predicate) 
constraints  instance(domai  n-typc(xriterion),.arg) 

TemporalPlan  enflag+output 
ro/esxn  flag(cond)  .output(flag) 
constraints  instance{jojn-output,.enflag.efld) 

A  .outpuLarg  =  .enflag.end.output 
A  apply(.output.criterion,.enflag.cnd.succeed-inpm)= mie 
A  app)y(.outputxriterion,xnflagxnd.fai]-input)= false 

TemporalPlan  enflag+dcflag  extension  enflag+output 
roles  xnflag(cond)  .output(flag)  .deflag(@predicate) 
constraints  .dcflag.criterion = .en  flag.ou  tpu  Leri  terion 
A  .enflag.cnd.output=.deflag.input 
A  cflow(enflag.end.out,.deflag.in) 

TemporalOverlay  cnflag+deflagMest1 :  enflag+deflag  -+  lest 
correspondences  enflag+dcflag.enflag.if.in = testin 
A  cnflag+deflag.deflag.succeed = tcstsucceed 
A  enflag^deflag.deflag.fail  =  testfail 


1.  See  Fig.  A-B. 
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